https://noxiouspl.uk/
Dat is mijn hele punt: maarja 1,0058 zal op computers met een Amerikaans locale anders parsen dan op computers met een Europees locale, dus je moet hier hoe dan ook afspraken over maken
@Janoz: om daar op verder te gaan, ik hoorde laatste het verhaal sommige zorgverzekeraars niet om kunnen gaan met tweelingen, omdat er maar 1 persoon in een gezin per dag geboren kan worden (unique identifier binnen een gezin was achternaam, geboortedatum, adres ofzoiets raars. Tweelingen werden als 'fix' dan op twee verschillende dagen geboren
Onzin. Hoe wil je dat ooit afdwingen?Orion84 schreef op dinsdag 03 augustus 2010 @ 13:05:
In Nederland is het afaik zo dat (geboortedatum, volledige naam, geboorteplaats) uniek is.
Ambtenaar burgerlijke stand: "Nee meneertje, u moet toch echt een andere naam voor uw kleintje verzinnen. Er is vandaag al iemand anders langs geweest die Piet Jansen heeft geregistreerd op deze datum en deze plaats."
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Kater? Eerst water, de rest komt later
{signature}
En dan kom je er achter dat niet iedereen een geboortedatum heeft (ECHT WAAR) ....Orion84 schreef op dinsdag 03 augustus 2010 @ 13:05:
In Nederland is het afaik zo dat (geboortedatum, volledige naam, geboorteplaats) uniek is.
En ook het begrip "naam" is niet zo simpel.
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
Maar niet ieder bedrijf heeft je sofi nummer...Voutloos schreef op dinsdag 03 augustus 2010 @ 13:24:
Nee je moet helemaal niet dat soort aannames maken. Je sofi/BSN is uniek en verder niet.
@leuk_he
hmm dat wist ik niet...Van vreemdelingen is vaak uitsluitend het geboortejaar bekend. Dan wordt in de GBA aan dat jaar de code 00 voor de maand en 00 voor de dag toegevoegd, de datum wordt dan jjjj0000. In een legitimatiebewijs, reisdocument of paspoort worden van die 0'en echter weer X'en gemaakt. Dag van geboorte-geboortemaand/geboortemaand in het Engels-geboortejaar wordt dan XX XXX/XXX geboortejaar.
[ Voor 46% gewijzigd door dragontje124 op 03-08-2010 13:31 ]
Ja, je zou in de praktijk natuurlijk altijd een BSN (sofinummer) gebruiken, maar dat was voor dit voorbeeld niet nodig.Janoz schreef op dinsdag 03 augustus 2010 @ 12:39:
Trouwens. Geboortedatum en naam is absoluut geen unieke key voor een persoon. Ikzelf ken iemand met dezelfde naam die op exact dezelfde dag geboren is als ik. Kwamen we in het ziekenhuis gelukkig op tijd achter. Ik heb alleen wel maanden geen studiefinanciering gehad omdat de andere 'janoz' bij een garage aan het werk was en (waarschijnlijk) mijn sofinummer gebruikte.
Ergens zou me dat niet eens verbazen. Al kan het best zijn dat ook de overige gegevens die in de geboorteakte staan worden meegenomen (ouder(s), geslacht).Janoz schreef op dinsdag 03 augustus 2010 @ 13:09:
[...]
Onzin. Hoe wil je dat ooit afdwingen?
Ambtenaar burgerlijke stand: "Nee meneertje, u moet toch echt een andere naam voor uw kleintje verzinnen. Er is vandaag al iemand anders langs geweest die Piet Jansen heeft geregistreerd op deze datum en deze plaats."
Ik weet niet in hoeverre het hard wordt afgedwongen en in hoeverre er vertrouwd wordt op die uniciteit, het is een typisch klok/klepel geval, dus ik zal verder m'n mond maar houden
[ Voor 3% gewijzigd door Orion84 op 03-08-2010 13:37 ]
The problem with common sense is that it's not all that common. | LinkedIn | Flickr
Daar hebben ze auto_increment klantnummers voor uitgevonden.dragontje124 schreef op dinsdag 03 augustus 2010 @ 13:30:
[...]
Maar niet ieder bedrijf heeft je sofi nummer...
{signature}
Ja, maar mijn hele punt is dat het nuttiger is om het getal 1,0058 op decimal-niveau te vergelijken dan om er eerst een string van te maken en die te vergelijken met een hardcoded "1,0058".roy-t schreef op dinsdag 03 augustus 2010 @ 12:43:
@ Davio
Dat is mijn hele punt: maarja 1,0058 zal op computers met een Amerikaans locale anders parsen dan op computers met een Europees locale, dus je moet hier hoe dan ook afspraken over maken.
@Janoz: om daar op verder te gaan, ik hoorde laatste het verhaal sommige zorgverzekeraars niet om kunnen gaan met tweelingen, omdat er maar 1 persoon in een gezin per dag geboren kan worden (unique identifier binnen een gezin was achternaam, geboortedatum, adres ofzoiets raars. Tweelingen werden als 'fix' dan op twee verschillende dagen geboren. (Komt vast van tdwtf ofzo).
Ik wil puur voorkomen dat mensen de gewoonte ontwikkelen om van objecten een string te maken en die te vergelijken in plaats van de daartoe bestemde Equals-methode te gebruiken.
De hele volgende discussie over het uniek zijn van verschillende combinaties is natuurlijk vrij nutteloos, alleen je BSN is uniek.
het BSN nummer is inderdaad alleen bedoeld voor communicate tussen de burger en overheid. Daarom ga je maar zelf klant nummers uitgeven. En een key gebruiken die eventueel kan veranderen is uiteraard een probleem (mensen kunnen hun BSN verkeerd opgeven, dan moet je wel correctie mogelijkheden hebben toch...)Voutloos schreef op dinsdag 03 augustus 2010 @ 13:36:
[...]
Daar hebben ze auto_increment klantnummers voor uitgevonden.
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
Grappig artikel maar wel erg academisch bekeken. Met veel aannames is weinig mis in bepaalde domeinen. Modellen zijn vereenvoudigingen, je hoeft niet alles te ondersteunen. Zo zijn 24-26 irrelevant in veel Westerse domeinen omdat fonetische transcriptie gebruikelijk is.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Verwijderd
BSN voor zoiets gebruiken is dus ook niet echt handig. Hiervoor gebruik je gewoon een eigen unieke nummer waarvan je kunt garanderen binnen je eigen domein dat het uniek is en dus gebruikt kan worden om iemand te identificeren.
Het artikel, maar vooral de reacties eronder, zijn erg vermakelijk. Ik heb zelf op enkele projecten gezeten waarbij we met GBA data moesten werken (en er een schaduw administratie van bij moesten houden) en ik ben inderdaad genoeg verbazingwekkende uitzonderingen tegen gekomen.
Het wordt trouwens pas echt spannend wanneer je naar adressen gaat kijken.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ik weet dat het in veel gevallen gebruikelijk is om een auto_increment integer te gebruiken als key / ID.
Onlangs kwam ik echter een situatie tegen waarin GUIDs gebruikt worden, dat vond ik ook wel een aardige oplossing. Je hebt als voordeel dat ze moeilijker te raden zijn, mocht iemand er proberen mee te willen sjoemelen.
In databases zijn twee null values niet gelijk aan elkaar.Verwijderd schreef op dinsdag 03 augustus 2010 @ 14:06:
Een BSN is absoluut niet uniek. Er zijn namelijk altijd een grote groep mensen die geen BSN hebben, ook wel buitenlanders genoemd. Daarnaast zijn er mensen die wel Nederlander zijn maar nog geen BSN hebben toegewezen gekregen.
Dat zou niets uit moeten maken, iemand moet nog steeds de autorisatie hebben over de data die bij de veranderde ID hoort. Alleen als je een token-achtig systeem gebruikt moet je geen incrementals gebruiken, zoals een collega van mij heeft gedaan.Davio schreef op dinsdag 03 augustus 2010 @ 15:03:
Nog even een sidenote over unieke nummers:
Ik weet dat het in veel gevallen gebruikelijk is om een auto_increment integer te gebruiken als key / ID.
Onlangs kwam ik echter een situatie tegen waarin GUIDs gebruikt worden, dat vond ik ook wel een aardige oplossing. Je hebt als voordeel dat ze moeilijker te raden zijn, mocht iemand er proberen mee te willen sjoemelen.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Als 'moeilijk te raden' en requirement is weet ik wel betere oplossingen dan een GUID gebruiken. Daarvoor kun je gewoon een autonummeringsschema gebruiken wat niet oplopend is. GUID is enkel een oplossing in situaties waarbij verschillende onderdelen uit dezelfde pool ID's uit moeten delen zonder dat ze met elkaar (of een derde autoriteit) kunnen communiceren. Alle andere toepassingen zijn IMHO luiheid van de ontwikkelaar / architect.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
ja dat klopt, daar doelde ik eigenlijk ook opVoutloos schreef op dinsdag 03 augustus 2010 @ 13:36:
[...]
Daar hebben ze auto_increment klantnummers voor uitgevonden.
Ehm, buitenlanders die hier zijn en netjes een visum hebben gehaald en/of zich gemeld hebben bij de gemeente krijgen van de Belastingdienst keurig netjes een BSN. Zelfs met een verblijfsvergunning voor bepaalde tijd. Mijn vrouw heeft die ook, staat alleen niet op haar verblijfsdocument maar, volgens mij, in haar paspoort bijgeschreven. Zonder de BSN krijg je simpelweg ook geen zorgverzekering, je BSN staat namelijk ook op het pasje van je zorgverzekeraar.Verwijderd schreef op dinsdag 03 augustus 2010 @ 14:06:
Een BSN is absoluut niet uniek. Er zijn namelijk altijd een grote groep mensen die geen BSN hebben, ook wel buitenlanders genoemd. Daarnaast zijn er mensen die wel Nederlander zijn maar nog geen BSN hebben toegewezen gekregen.
dat is juist een slecht programmeer voorbeeld :-) Je mag het BSN/sofi nummer niet vragen en niet opslaan. Er zijn een paar uitzonderingen die ik zo niet kan noemen maar ga er maar vanuit dat het niet mag.Davio schreef op dinsdag 03 augustus 2010 @ 13:32:
[...]
Ja, je zou in de praktijk natuurlijk altijd een BSN (sofinummer) gebruiken, maar dat was voor dit voorbeeld niet nodig.
Tja, dat krijg je met zo'n standaard naamJanoz schreef op dinsdag 03 augustus 2010 @ 12:39:
Trouwens. Geboortedatum en naam is absoluut geen unieke key voor een persoon. Ikzelf ken iemand met dezelfde naam die op exact dezelfde dag geboren is als ik. Kwamen we in het ziekenhuis gelukkig op tijd achter. Ik heb alleen wel maanden geen studiefinanciering gehad omdat de andere 'janoz' bij een garage aan het werk was en (waarschijnlijk) mijn sofinummer gebruikte.
[ Voor 84% gewijzigd door .oisyn op 03-08-2010 16:01 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nu ga je ervan uit dat fonetische transcriptie genoeg is om die namen af te handelen, (hoeft niet eens, omdat unicode in meer systemen ondersteund wordt dan je denkt). Echter het begrip voornaam, achternaam en tussenvoegsel zijn wellicht moeilijk te mappen op aziatische namen.kenneth schreef op dinsdag 03 augustus 2010 @ 13:43:
[...]
Grappig artikel maar wel erg academisch bekeken. Met veel aannames is weinig mis in bepaalde domeinen. Modellen zijn vereenvoudigingen, je hoeft niet alles te ondersteunen. Zo zijn 24-26 irrelevant in veel Westerse domeinen omdat fonetische transcriptie gebruikelijk is.
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
Ik snap ook wel dat je voor een GBA moet je met veel meer (opmerkelijke) zaken rekening moet houden maar als ik de ledenadministratie van de scouting wil bijhouden of de klanten van mijn webwinkeltje een account wil geven dan zijn veel aannames lang niet zo dodelijk.
Voorbeeld: IJsland. Een land zonder achternamen. Komt een IJslander naar Nederland, wij doen alsof Magnúsdóttir een achternaam is, probleem opgelost. Het pakketje met bestelde boeken komt nog steeds aan en haar dochter, die (incorrect) ook Magnúsdóttir heeft mag nog gewoon mee met het scoutingweekend.
[ Voor 30% gewijzigd door kenneth op 03-08-2010 16:11 ]
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Tussenvoegsel is dan wel weer een mooi voorbeeld van het probleem. Dat hebben we namelijk alleen bij Nederlandse namen. In systemen waar geen rekening hiermee gehouden wordt heet ik ineens De Vries (ipv de Vries), ben ik te vinden onder de D, denken ze dat De ook een naam is en/of is mijn achternaam gewoon Devries.leuk_he schreef op dinsdag 03 augustus 2010 @ 16:03:
[...]
Nu ga je ervan uit dat fonetische transcriptie genoeg is om die namen af te handelen, (hoeft niet eens, omdat unicode in meer systemen ondersteund wordt dan je denkt). Echter het begrip voornaam, achternaam en tussenvoegsel zijn wellicht moeilijk te mappen op aziatische namen.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Zeker als het om gebruikersinformatie gaat. Je hebt vaak ook twee keuzes.
a) Je kunt proberen alle verschillende varianten te ondervangen, waardoor je klanten kunt helpen als ze per ongeluk iets fout invullen en fouten vooraf kunt afvangen. Kost veel tijd en geld doorgaans.
b) Je kunt klanten gewoon zelf van alles in laten vullen en zelf de gevolgen laten ondervinden van een verkeerd ingevuld veld (bijvoorbeeld dat pakketjes niet aankomen).
Schrikkeljaren zijn ook altijd een mooi programmatisch probleem, al ondersteunen de meeste zichzelf respecterende API's dat gewoon.
Maar nog iets met de zomer- en wintertijd. Een (log)bestand van 2:01 van ná het ingaan van de wintertijd is nieuwer dan een bestand van 02:59 van vóór het ingaan van de wintertijd, al zou menig systeem dat andersom zien. En nu kun je een systeem alle moeite laten doen om dat te begrijpen en bij elke sortering de 2 bestanden andersom te zetten, of je kunt het zo laten en de gebruiker die ontdekking laten doen.
Vlamingen plakken gewoon alles achter elkaar.Janoz schreef op dinsdag 03 augustus 2010 @ 16:24:
[...]
Tussenvoegsel is dan wel weer een mooi voorbeeld van het probleem. Dat hebben we namelijk alleen bij Nederlandse namen. In systemen waar geen rekening hiermee gehouden wordt heet ik ineens De Vries (ipv de Vries), ben ik te vinden onder de D, denken ze dat De ook een naam is en/of is mijn achternaam gewoon Devries.
Vandenbroecke, Vanderelst, etc...
Betere oplossing: niet uitgaan van tijd/dag/datum schrikkeljaar, maar gewoon sorteren op unixtime of iets in die geest, dan gaat het altijd wel goedDavio schreef op dinsdag 03 augustus 2010 @ 16:31:
Ach, het is al jaren zo dat programmeurs een imperfecte wereld moeten modelleren en dan moeten er wel eens keuzes gemaakt worden.
Zeker als het om gebruikersinformatie gaat. Je hebt vaak ook twee keuzes.
a) Je kunt proberen alle verschillende varianten te ondervangen, waardoor je klanten kunt helpen als ze per ongeluk iets fout invullen en fouten vooraf kunt afvangen. Kost veel tijd en geld doorgaans.
b) Je kunt klanten gewoon zelf van alles in laten vullen en zelf de gevolgen laten ondervinden van een verkeerd ingevuld veld (bijvoorbeeld dat pakketjes niet aankomen).
Schrikkeljaren zijn ook altijd een mooi programmatisch probleem, al ondersteunen de meeste zichzelf respecterende API's dat gewoon.
Maar nog iets met de zomer- en wintertijd. Een (log)bestand van 2:01 van ná het ingaan van de wintertijd is nieuwer dan een bestand van 02:59 van vóór het ingaan van de wintertijd, al zou menig systeem dat andersom zien. En nu kun je een systeem alle moeite laten doen om dat te begrijpen en bij elke sortering de 2 bestanden andersom te zetten, of je kunt het zo laten en de gebruiker die ontdekking laten doen.
Btw zat de 'unix millenium bug' er niet aan te komen?
De unix epoch rollover is pas in 2038, dus dat duurt nog evenroy-t schreef op dinsdag 03 augustus 2010 @ 17:24:
[...]
Btw zat de 'unix millenium bug' er niet aan te komen?
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Die is toch "opgelost" met 64bit?roy-t schreef op dinsdag 03 augustus 2010 @ 17:24:
[...]
Btw zat de 'unix millenium bug' er niet aan te komen?
Overigens rolt ie alleen over in 2038 als je 'm als signed behandelt. Voor unsigned 32 bit timestamps kunnen we tot 2106 vooruit.
[ Voor 50% gewijzigd door .oisyn op 03-08-2010 18:08 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Impedance, a measure of opposition to time-varying electric current in an electric circuit.
Not to be confused with impotence.
Zeker als er over een paar jaar alleen nog maar 64-bits (of zelfs al meer) OSen uitkomen. Dan is de overstap al een stukje kleinerbobo1on1 schreef op dinsdag 03 augustus 2010 @ 18:10:
Dan moeten we wel allemaal overgestapt zijn tegen die tijd.
If money talks then I'm a mime
If time is money then I'm out of time
We are shaping the future
If money talks then I'm a mime
If time is money then I'm out of time
Erger nog, ik heb zelf van die bagger geproduceerd. Maar toen was ik 16. De site waar ik toen aan heb meegewerkt staat nu nog live en ik weet dat hij vol leaks zit.
We are shaping the future
Kan je eens een voorbeeld geven van iets dat beter is dan een GUID?Janoz schreef op dinsdag 03 augustus 2010 @ 15:11:
Eigenlijk is het altijd te prefereren om een niet betekenisvolle gegarandeerd unieke identifier zoals een auto_increment te gebruiken.
Als 'moeilijk te raden' en requirement is weet ik wel betere oplossingen dan een GUID gebruiken. Daarvoor kun je gewoon een autonummeringsschema gebruiken wat niet oplopend is. GUID is enkel een oplossing in situaties waarbij verschillende onderdelen uit dezelfde pool ID's uit moeten delen zonder dat ze met elkaar (of een derde autoriteit) kunnen communiceren. Alle andere toepassingen zijn IMHO luiheid van de ontwikkelaar / architect.
Enige wat ik kan bedenken wat niet 'oplopend' is zou een autoincrement zijn die ik door encryptie heen haal, maar dan vind ik eigenlijk GUID mooier omdat die voor zover ik weet in het OS zelf zit.
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
Er zijn vele mogelijkheden om een systeem te genereren die een (pseudo)random unieke reeks genereren (al was het maar door telkens random een item uit een lijst van uit te geven nummers te halen)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
/edit, opzich is 128 bits random niet gegarandeert uniek, maar de kans dat ik 2 verschillende loterijen op 1 dag win ondanks dat ik er aan 0 mee doe is groter.
[ Voor 54% gewijzigd door PiepPiep op 04-08-2010 09:38 ]
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
/edit
Dus als je optie 1 hebt die random is en optie 2 die random en gegarandeerd uniek is dan is optie 2 automatisch beter wanneer uniek zijn een requirement is.
Dat de kans erop nagenoeg 0 is betekend nog dat hij ook 0 is. In veel gevallen zal bijna uniek vast wel genoeg zijn (wanneer je achteraf redelijk simpel de PK aan kunt passen wanneer je daadwerkelijk een conflict detecteerd), maar het uitgeven van bijvoorbeeld BSN nummers lijkt mij niet iets wat je met een GUID achtige aanpak op moet gaan lossen.
[ Voor 86% gewijzigd door Janoz op 04-08-2010 09:42 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Oké, ik snap dat GUIDs handig zijn voor systemen die een globaal unieke code moeten genereren zonder dat ze kunnen communiceren met de buitenwereld om te controleren of de code uniek is, maar waarom zou je deze al bestaande functionaliteit dan zelf niet kunnen gebruiken.
Het is niet zo dat ze dan heel snel opraken ofzo, en als dat wel dreigt te gebeuren, dan verdubbelen ze het aantal bits gewoon.
* Reptile209 heeft Van 't Sant als achternaam. Ik heb mezelf ooit teruggevonden op een alfabetische lijst vóór de A, waar ik als 't Sant, van, Koen vermeld stond... Buitenlanders komen er meestal ook niet helemaal uit. En ik heb bergen moeten verzetten om de apostrof uit mijn eerste emailadres te laten halen, daar werden veel webforms ook niet vrolijk van. En hoe vaak ik niet een escape-slash in automatische antwoordberichten in mijn naam tegenkom...Janoz schreef op dinsdag 03 augustus 2010 @ 16:24:
[...]
Tussenvoegsel is dan wel weer een mooi voorbeeld van het probleem. Dat hebben we namelijk alleen bij Nederlandse namen. In systemen waar geen rekening hiermee gehouden wordt heet ik ineens De Vries (ipv de Vries), ben ik te vinden onder de D, denken ze dat De ook een naam is en/of is mijn achternaam gewoon Devries.
</namenrant>
Zo scherp als een voetbal!
1
2
3
4
5
6
7
| <?php $array[] = 'blaat'; //of $string .= 'blaat'; ?> |
Je kan wel nagaan (ik heb als ik programmeer error_reporting aan staan) dat ik dan behoorlijk wat "undefined variable" of "undefined index" warnings krijg. Heel irritant, het is ook gewoon niet netjes.
Nee, GUID's zijn ontwikkeld om in een omgeving waarin vele ongerelateerde partijen elk uit dezelfde pool id's moeten kunnen halen zonder een centraal uitdeel orgaan. In die context proberen ze de identifier zo uniek mogelijk te houden. Voor schrijvers van activeX plugins DLL's en andere componenten in Windows is het natuurlijk ondoenlijk om elke keer op de MS website een ID aan te vragen. Zeker in een tijd waarin het internet nog lang niet zo breed toegankelijk is.Davio schreef op woensdag 04 augustus 2010 @ 09:39:
Dat vraag ik me af omdat GUIDs speciaal voor dat doel zijn ontwikkeld (om allemaal uniek te zijn), waarom zou je dan het wiel opnieuw uit willen vinden?
Binnen die context is het logisch dat er geen 100% garantie op uniekheid gegeven kan worden.
Omdat er veel betere standaard alternatieven zijn zoals een auto_increment/sequence?Oké, ik snap dat GUIDs handig zijn voor systemen die een globaal unieke code moeten genereren zonder dat ze kunnen communiceren met de buitenwereld om te controleren of de code uniek is, maar waarom zou je deze al bestaande functionaliteit dan zelf niet kunnen gebruiken.
Waarna vele applicaties ineens krak zeggen omdat ze voor de GUID slechts 128 bits gereserveerd hebben. Daarnaast weet je helemaal niet dat het 'op' aan het raken is. De enige manier om te achterhalen dat je een sleutel dubbel uitgegeven hebt is wanneer dingen compleet de mist in lopen te gaan. (Hoe moet een leek achterhalen dat hij binnen zijn thuis netwerk per ongeluk twee netwerkkaarten met hetzelfde MAC adres en wat hij daar uberhaupt aan kan doen?)Het is niet zo dat ze dan heel snel opraken ofzo, en als dat wel dreigt te gebeuren, dan verdubbelen ze het aantal bits gewoon.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Wil je dat mensen netter programmeren, moet je een strictere taal nemen.
En ja -1 is de magische alles voor zowel nu als in de toekomst, iets E_ALL vooral niet is.
{signature}
Die kende ik nog niet, ik zet zelf E_ALL, E_NOTICE, E_DEPRECATED aan (standaard rijtje voor mij) in de code.Voutloos schreef op woensdag 04 augustus 2010 @ 10:12:
Nou ja, al je collega PHPers moeten gewoon ook altijd met error_reporting(-1) werken.
offtopic:
En ja -1 is de magische alles voor zowel nu als in de toekomst, iets E_ALL vooral niet is.
@Davio
De taal is daar slechts deels schuldig aan, hij ziet het wel als fout (dat op zichzelf is toch redelijk strict) maar hij maakt op dat moment ter plekke de variabele zelf aan. Op zich vind ik dat (in dit soort zaken( helemaal niet verkeerd dat die dat doet, maar de fout (misschien ander type) mag van mij wel op een dusdanige manier werken dat ze wel getoond worden, zodat je meer gedwongen wordt om het wel goed / netjes te doen.
Er zijn meer talen waarbij je niet hoeft te declareren, dat op zichzelf is niet fout, maar als je het als fout ziet moet je het ook als fout weergeven en niet als "Let op dat je iets niet helemaal juist heb gedaan, maar het werkt wel, je kan deze fout "oplossen" door de waarschuwingen uit te schakelen", gewoon altijd tonen is in mijn mening de beste manier.
[ Voor 49% gewijzigd door jbdeiman op 04-08-2010 10:18 ]
Oneens, dat een taal je vrijheden geeft betekent niet altijd dat je ze moet gebruiken. Het is een kwestie van conventies afspreken.Davio schreef op woensdag 04 augustus 2010 @ 09:59:
Mjah, maar dat krijg je met zo'n loose taal als PHP.
Wil je dat mensen netter programmeren, moet je een strictere taal nemen.
Afspreken dat code geen notices geeft lijkt me een goede afspraak om te hebben, dat is ook prima (zelfs geautomatiseerd) te verifieren.
De enige caveat die ik heb gezien is dat de computer een netwerk kaart moet hebben (want GUIDs zijn uniek omdat het MAC adres wordt gebruikt voor een deel van de GUID, en MAC adressen zijn weer uniek omdat elke fabrikant van netwerkapparatuur zijn eigen deel van de MAC adressen beheert en zodoende er voor kan zorgen dat elk nummer maar 1 keer wordt uitgegeven).
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Sinds wanneer kan dat voorkomen? Het (hardware) MAC adres is juist gegarandeerd uniek, of zou iig zo moeten zijn. Versie 1 van het GUID algoritme gebruikte het MAC adres ook om uniciteit te kunnen garanderen, al bracht dat natuurlijk wat privacy issues met zich mee (hoewel de maker van de Melissa worm hierdoor wel gepakt kon worden)Janoz schreef op woensdag 04 augustus 2010 @ 09:52:
(Hoe moet een leek achterhalen dat hij binnen zijn thuis netwerk per ongeluk twee netwerkkaarten met hetzelfde MAC adres en wat hij daar uberhaupt aan kan doen?)
.edit: misschien moet ik eerst refreshen
Het burned-in adres kun je niet wijzigen.Cartman! schreef op woensdag 04 augustus 2010 @ 10:58:
Een MAC-adres is niet per definitie uniek omdat je deze zelf kunt wijzigen.
Dat zou niet eens mogen gebeuren.Creepy schreef op woensdag 04 augustus 2010 @ 11:02:
Sterker nog: ik heb twee moederborden gezien (hetzelfde merk en type) met een onboard netwerkkaart en die twee PC's hadden steeds problemen met hun netwerk. Wat bleek: ze hadden allebei hetzelfde MAC-adres.
[ Voor 60% gewijzigd door .oisyn op 04-08-2010 11:32 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Niet, maar het uitdelen van MAC adressen gebeurt dan ook niet middels MS's GUID implementatie, maar gewoon (Net als bij bluetooth) middels het toekennen van bepaalde ranges aan bedrijven die vervolgens binnen die range de opdracht krijgt de boel uniek te houden. Het was echter even een voorbeeld van een probleem dat op zou kunnen treden wanneer je aanneemt dat iets wel uniek zal zijn en daarmee een dikke middelvinger richting Murphy doet..oisyn schreef op woensdag 04 augustus 2010 @ 11:23:
Sinds wanneer kan dat voorkomen?
[ Voor 9% gewijzigd door Janoz op 04-08-2010 11:34 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Verwijderd
1
| btnSubmit.Attributes.Add("onclick", "javascript:if(validation()==false) return false"); |
1
2
3
4
5
| function validation() { if (someVar == "xyz") { return true; // validation successful } return false; // validation failed, this will stop the form submiting } |
MAC adres is NIET uniek. Heel vaak komt het voor dat bijvoorbeeld USA, Europe en Asia dezelfde MAC adressen hebben omdat de kans dat die batches samen in één netwerk terecht komen minimaal is..oisyn schreef op woensdag 04 augustus 2010 @ 11:23:
[...]
Sinds wanneer kan dat voorkomen? Het (hardware) MAC adres is juist gegarandeerd uniek, of zou iig zo moeten zijn. Versie 1 van het GUID algoritme gebruikte het MAC adres ook om uniciteit te kunnen garanderen, al bracht dat natuurlijk wat privacy issues met zich mee (hoewel de maker van de Melissa worm hierdoor wel gepakt kon worden)
.edit: misschien moet ik eerst refreshen
[...]
Het burned-in adres kun je niet wijzigen.
[...]
Dat zou niet eens mogen gebeuren.
'You like a gay cowboy and you look like a gay terrorist.' - James May
Maar standaarden bestaan ook niet in de praktijk.
Klopt, maar het gebeurt regelmatig dat b.v. hetzelfde adres wordt uitgedeeld aan twee NICs waarvan b.v. een naar de US en de ander naar Europa geshipt zal worden. Het MAC adres hoeft technisch gezien alleen uniek te zijn in een lokaal netwerk segment, dus de kans is minimaal dat dat ooit problemen op gaat leveren. Hiermee omzeilen sommige leveranciers het aanvragen van een nieuwe range.
XT, 640K ram, 20 MB harddisk, MS-DOS 4.0...
Ik heb eens een wifi kaart gehad die hetzelfde mac adres had als een wifi usb stick van een ander merk, dan sta je ook wel even te kijken.Creepy schreef op woensdag 04 augustus 2010 @ 11:02:
Sterker nog: ik heb twee moederborden gezien (hetzelfde merk en type) met een onboard netwerkkaart en die twee PC's hadden steeds problemen met hun netwerk. Wat bleek: ze hadden allebei hetzelfde MAC-adres. Gelukkig kon die worden aangepast in de bios..... Ook een GUID is niet 100% gegarandeerd uniek. Maar de kans dat je op twee verschillende systemen dezelfde krijgt is heel erg klein.
Impedance, a measure of opposition to time-varying electric current in an electric circuit.
Not to be confused with impotence.
Verwijderd
Dit lijkt me niet mogelijk?bobo1on1 schreef op woensdag 04 augustus 2010 @ 14:31:
[...]
Ik heb eens een wifi kaart gehad die hetzelfde mac adres had als een wifi usb stick van een ander merk, dan sta je ook wel even te kijken.
Dat is inderdaad zeer onwaarschijnlijk omdat merken ranges moeten registeren. Op de site van de IEEE zijn de verschillende "Organizational Unique Identifier" te vinden. Misschien dat iemand ooit het adres heeft aangepast.
'You like a gay cowboy and you look like a gay terrorist.' - James May
De kans dat je exact hetzelfde MAC-adres tegenkomt is nog kleiner dan dat je miljonair wordt in de Sponsor Bingo Loterij.
If money talks then I'm a mime
If time is money then I'm out of time
Merken als Icidu en Eminent zie ik bijvoorbeeld niet terugkomen in die lijst, om maar wat te noemen.
The problem with common sense is that it's not all that common. | LinkedIn | Flickr
[ Voor 5% gewijzigd door .oisyn op 04-08-2010 16:41 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Uiteraard zit de echte wtf in het puntje dat de } uitgecommentaard wordtVerwijderd schreef op woensdag 04 augustus 2010 @ 11:49:
Kwam zonet deze tegen op de asp.net forums. Werd als advies gegeven nota bene:
C#:
1 btnSubmit.Attributes.Add("onclick", "javascript:if(validation()==false) return false");
JavaScript:
1 2 3 4 5 function validation() { if (someVar == "xyz") { return true; // validation successful } return false; // validation failed, this will stop the form submiting }
[ Voor 31% gewijzigd door daniëlpunt op 04-08-2010 17:25 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Maar ja, client-side validatie doe je voor je clients en server-side doe je voor jezelf.
Hoeft niet altijd zo te zijn.Sebazzz schreef op woensdag 04 augustus 2010 @ 17:26:
Aan dat programmeerwerk te zien kan je voorspellen dat de site van client-side validatie uit gaat en hoopt dat de client zich aan de validatieregels (maxlength, numbers) houdt en dat de JS ook valideert.
Als ik ooit een webbased spelletje zou maken zou ik de client alles laten valideren en daarna op de server nog eens. Als ik op de server dan een fout tegen komt die de client eruit gehaald zou moeten hebben kan ik die speler bannen
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
Verwijderd
Volgens mij bedoelde hij het enigzins sarcastischPiepPiep schreef op woensdag 04 augustus 2010 @ 18:43:
[...]
Hoeft niet altijd zo te zijn.
Als ik ooit een webbased spelletje zou maken zou ik de client alles laten valideren en daarna op de server nog eens. Als ik op de server dan een fout tegen komt die de client eruit gehaald zou moeten hebben kan ik die speler bannen
Beter om wel altijd brackets te gebruiken, anders krijg je weer problemen als je later wat regels code toevoegt aan de if/else en vergeet dat ze dan wél nodig zijn.daniëlpunt schreef op woensdag 04 augustus 2010 @ 17:23:
ik vind het meer een wtf waarom hij daar überhaupt curly brackets gebruikt als het toch op 1 regel staat. maar goed, programmeer het laatste jaar veel Ruby en daar gebruik je erg weinig curly brackets
Tenzij je bedoelt dat er in dit geval ook gewoon
1
| return someVar == "xyz"; |
had kunnen staan. Maar waarschijnlijk is het voorbeeld vereenvoudigd.
Kater? Eerst water, de rest komt later
1
| btnSubmit.Attributes.Add("onclick", "javascript:return someVar==\"xyz\""); |
[ Voor 184% gewijzigd door Jaap-Jan op 04-08-2010 19:15 ]
| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett
Verwijderd
Het was eigenlijk een voorbeeld om te demonstreren hoe je met "return false" de automatische submit van een serverside asp.net button kan opvangen. Alleen ietsje omslachtiger dan ik het zou gedaan hebbenSebazzz schreef op woensdag 04 augustus 2010 @ 17:26:
Aan dat programmeerwerk te zien kan je voorspellen dat de site van client-side validatie uit gaat en hoopt dat de client zich aan de validatieregels (maxlength, numbers) houdt en dat de JS ook valideert.
Dat dus vooral....There's no difference betweeen <![CDATA[C]]> and just C from an XML
point of view... It's the same, just differently serialized
[ Voor 50% gewijzigd door Cartman! op 05-08-2010 09:39 ]
Om eerlijk te zijn: het zijn de beste die ik ooit gehad heb qua ontvangst
Maarrrrr... Ik had er een in m'n laptop zitten, en propte er een in mn pc. Niet meer te connecten met geen mogelijkheid met beide.. Wat bleek? Alle sticks uit die serie hadden hetzelfde MAC adres
https://noxiouspl.uk/
Ik zou me kunnen voorstellen dat dat samengaat met een Bluetoothlicentie oid, want voor $1.80 daar kunnen haast geen licentiekosten in zitten zou je zeggenDavio schreef op donderdag 05 augustus 2010 @ 10:07:
Moeten bedrijven ook geld betalen voor een sloot MAC-adressen? Anders is het wel heel logisch dat er gesjoemeld wordt, en het scheelt in het productieproces natuurlijk ook weer geld.
Overigens weet ik wel dat MAC adressen per regio worden uitgegeven, dus in Amerika kun je dezelfde tegenkomen als in Europa of Azie. Dat kan misschien wat verklaren mbt import en dergelijke.
https://noxiouspl.uk/
Verwijderd
Dit probleem was primair bij enkele reeksen van moederborden van Asus met een SIS chipset (ik kan fout zitten, lang geleden, maar 99% zeker dat het Asus/SIS was). Maar die reeks was niet de enigste. Dus conclusie: zelfs zonder gesjoemel of import. Zelfs bij in Nederland gekochte spullen gaat het fout. Dit gaf zelfs 'echte' problemen: klanten met zo'n duplicaat MAC-adres konden geen internet ontvangen in de set up van die interrnetprovider.
Tsja
https://noxiouspl.uk/
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ja er moet wel betaald worden, maar dat is maar een heel klein bedrag, en eigenlijk alleen administratie kosten. ( http://standards.ieee.org/regauth/oui/forms/ ), en dat valt dus in het niet als je grote hoeveelheden van dergelijke apparaten maakt.Davio schreef op donderdag 05 augustus 2010 @ 10:07:
Moeten bedrijven ook geld betalen voor een sloot MAC-adressen? Anders is het wel heel logisch dat er gesjoemeld wordt, en het scheelt in het productieproces natuurlijk ook weer geld.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
En dat verbaast je?.oisyn schreef op donderdag 05 augustus 2010 @ 12:02:
Blijkbaar was mijn vertrouwen in dat soort instanties dus compleet ongegrond
[ Voor 18% gewijzigd door .oisyn op 05-08-2010 13:57 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Volgens mij zijn het merendeel van de problemen die er zijn met dubbele MAC adressen, gewoon software matige problemen. Ik heb het idee dat de adressen die hard in de devices staan wel gewoon goed uitgedeeld worden ( Al zal daar vast wel eens wat administratief mis gaan ). De voorbeelden die je hierboven aangehaald ziet worden zijn ook problemen met drivers, of images die MAC-Spoofing gebruiken..oisyn schreef op donderdag 05 augustus 2010 @ 13:55:
Ja, omdat het zo doodsimpel is om ervoor te zorgen dat je gewoon unieke nummers uitgeeft. Ik wist dat elke vendor zijn eigen range kon registreren, daarna is het gewoon simpelweg een interne kwestie van "auto_increment". Én omdat het MAC adres altijd gezien werd als dé manier om voor een PC een uniek nummer te krijgen.
Ik zou het erg vreemd vinden als er in hardware dubbele adressen gestopt zijn, vanuit het oogpunt van besparing. Een blok van meer dan 16 miljoen adressen ( Met MAC-48 ) kost minder dan $ 2000,- en dus kost het 0,0125 dollar cent per device. Dat zijn niet echt bedragen om op te bezuinigen, zelfs niet als je in hele grote aantallen werkt. Met OUI-64 zijn de kosten nog een factor 65536 minder.
[ Voor 4% gewijzigd door Woy op 05-08-2010 14:32 ]
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
of wat als een pc in je netwerk hetzelfde mac adres heeft als bijvoorbeeld een server van google waar je naar probeert te connecten. kom je toch echt verkeerd uit.
Assumptions are the mother of all fuck ups | iRacing Profiel
[ Voor 36% gewijzigd door .oisyn op 05-08-2010 14:37 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Niet zozeer. Het is een adres wat alleen op de link gebruikt word. Je krijgt pas echte problemen als er bijvoorbeeld 2 nic's met hetzelfde mac adres op een switch zitten aangesloten.Salandur schreef op donderdag 05 augustus 2010 @ 14:34:
ik als softwareontwikkelaar vraag me dan weer af hoe dat zit met internet. Wat gebeurd er als er daar 2 nics met hetzelfde mac adres zijn.
of wat als een pc in je netwerk hetzelfde mac adres heeft als bijvoorbeeld een server van google waar je naar probeert te connecten. kom je toch echt verkeerd uit.
De routering over internet gaat gewoon op basis van IP adres, en dus heeft niet zo heel veel last van dubbele MAC adressen. Maar binnen 1 netwerk van een provider kan het wel zo zijn dat er aan de hand van MAC adressen gerouteerd word.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
De besparing lijkt me dan ook niet zitten in het kopen van de adressen, maar het in opzetten van je productielijn zodat die niet bij ieder apparaat een ander MAC adres hoeft toe te passen. Simpelweg 10.000x hetzelfde maken en dan het apparaat instellen op een nieuw adres is een stuk eenvoudiger en goedkoper.Woy schreef op donderdag 05 augustus 2010 @ 14:30:
[...]
Ik zou het erg vreemd vinden als er in hardware dubbele adressen gestopt zijn, vanuit het oogpunt van besparing. Een blok van meer dan 16 miljoen adressen ( Met MAC-48 ) kost minder dan $ 2000,- en dus kost het 0,0125 dollar cent per device. Dat zijn niet echt bedragen om op te bezuinigen, zelfs niet als je in hele grote aantallen werkt. Met OUI-64 zijn de kosten nog een factor 65536 minder.
Maar dan zou je suggereren dat er in grote oplage dubbele adressen zijn uitgedeeld, en dan is het voor de producent natuurlijk wachten op problemen, immers zal een batch redelijk tegelijk uitgedeeld worden, en is het dus ook niet gek dat er 2 devices met 1 adres op dezelfde plek aankomen. Natuurlijk kun je dat weer oplossen door een ingewikkelde distributie op te zetten, maar dan heeft het ook geen positief effect meer op de kosten.Stoffel schreef op donderdag 05 augustus 2010 @ 14:38:
[...]
De besparing lijkt me dan ook niet zitten in het kopen van de adressen, maar het in opzetten van je productielijn zodat die niet bij ieder apparaat een ander MAC adres hoeft toe te passen. Simpelweg 10.000x hetzelfde maken en dan het apparaat instellen op een nieuw adres is een stuk eenvoudiger en goedkoper.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
De adressen in de devices zijn ook niet goed omdat ze adressen hergebruiken, sowieso gebeurt dit al per regio (USA, Europe en Asia). Het is misschien niet de besparing per apparaat maar eerder in het hergebruiken van bestaande productielijnen.Woy schreef op donderdag 05 augustus 2010 @ 14:30:
[...]
Volgens mij zijn het merendeel van de problemen die er zijn met dubbele MAC adressen, gewoon software matige problemen. Ik heb het idee dat de adressen die hard in de devices staan wel gewoon goed uitgedeeld worden ( Al zal daar vast wel eens wat administratief mis gaan ). De voorbeelden die je hierboven aangehaald ziet worden zijn ook problemen met drivers, of images die MAC-Spoofing gebruiken.
Ik zou het erg vreemd vinden als er in hardware dubbele adressen gestopt zijn, vanuit het oogpunt van besparing. Een blok van meer dan 16 miljoen adressen ( Met MAC-48 ) kost minder dan $ 2000,- en dus kost het 0,0125 dollar cent per device. Dat zijn niet echt bedragen om op te bezuinigen, zelfs niet als je in hele grote aantallen werkt. Met OUI-64 zijn de kosten nog een factor 65536 minder.
'You like a gay cowboy and you look like a gay terrorist.' - James May
¸.·´¯`·.¸.·´¯`·.¸><(((º>¸.·´¯`·.¸><(((º>¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸<º)))><¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸
Het MAC adres kan er gewoon na de productie worden ingebrand. Dat doe je dan bijv. tijdens het testen van de chips.Stoffel schreef op donderdag 05 augustus 2010 @ 14:38:
[...]
De besparing lijkt me dan ook niet zitten in het kopen van de adressen, maar het in opzetten van je productielijn zodat die niet bij ieder apparaat een ander MAC adres hoeft toe te passen. Simpelweg 10.000x hetzelfde maken en dan het apparaat instellen op een nieuw adres is een stuk eenvoudiger en goedkoper.
[ Voor 65% gewijzigd door .oisyn op 05-08-2010 14:43 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Sole survivor of the Chicxulub asteroid impact.
De productielijn zal sowieso toch ingericht moeten zijn om per device een ander adres in te kunnen schieten, dus wat is dan de moeite om dat wereldwijd uniek te maken. Dat is een puur administratief proces. Ik zie echt niet het voordeel om in Europa en Amerika een adres range een keer te gebruiken, want je moet sowieso administratie bijhouden welk adres je al gebruikt hebt. Desnoods koop je per regio gewoon een adres blok, dan weet je zeker dat het niet mis gaat.Phyxion schreef op donderdag 05 augustus 2010 @ 14:40:
[...]
Het is misschien niet de besparing per apparaat maar eerder in het hergebruiken van bestaande productielijnen.
Maar we gaan aardig off-topic, want het heeft niks meer met slechte programmeervoorbeelden of überhaupt met PRG te maken
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Dit topic is gesloten.
![]()
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes.