De Devschuur Coffee Corner - Iteratie 2

[Firesphere]

Styxxy schreef op dinsdag 17 juli 2012 @ 14:18:
Het is toch fijn om gratis internet op de trein in Nederland te hebben. Kan ik rustig GoT lezen (loop een paar dagen achter ) en kan ik ook ineens mijn mailbox bekijken en sommige mails al snel beantwoorden .

Wen er maar niet te snel aan, per 2013 is er weinig gratis meer aan...

[Styxxy]

Firesphere schreef op dinsdag 17 juli 2012 @ 14:27:
[...]
Wen er maar niet te snel aan, per 2013 is er weinig gratis meer aan...

Aw . Ach, ik ben toch niet zo vaak in NL en binnen enkele maanden heb ik een eigen auto . Dan hoef ik de trein niet meer te nemen (of toch niet zo vaak meer).

[Alex)]

Firesphere schreef op dinsdag 17 juli 2012 @ 14:27:
[...]

Wen er maar niet te snel aan, per 2013 is er weinig gratis meer aan...

Dat is toch nog geen uitgemaakte zaak?

[Korben]

Alex) schreef op dinsdag 17 juli 2012 @ 14:22:
[...]

4.3.1 is de laatste stable die NuGet levert. Helaas is dat voor .NET 4.0, terwijl ik noodgedwongen nog op .NET 3.5 zit dankzij een groep collega's van de EF-developers. Daar kan ik ook niks aan doen he

Je kunt je project toch gewoon als .NET 4 builden en die Microsoft.SharePoint.dll gebruiken? Backwards compatibility is niet zo'n probleem bij .NET. Of werkt SharePoint gewoon niet onder ASP.NET 4?

[Alex)]

.NET 3 en .NET 3.5 zijn gebouwd op de CLR van .NET 2.0. .NET 4.0 brengt een geheel nieuwe CLR met zich mee, en dat breekt backwards compatability helaas wel

Voor zover ik kan nagaan kun je Microsoft.SharePoint.dll niet inladen in een .NET 4.0-omgeving.

[Firesphere]

Alex) schreef op dinsdag 17 juli 2012 @ 14:47:
[...]

Dat is toch nog geen uitgemaakte zaak?

Niet?
Staat me vaag ergens bij dat't al wel rond was, maar zo niet, dan hoop ik dat't "niet" blijft in ieder geval.

[Alex)]

Firesphere schreef op dinsdag 17 juli 2012 @ 14:50:
[...]

Niet?
Staat me vaag ergens bij dat't al wel rond was, maar zo niet, dan hoop ik dat't "niet" blijft in ieder geval.

De bedoeling is dat eind 2013 alle intercity's internet aan boord hebben. De internetverbinding blijft in ieder geval tot 1 april 2013 gratis; op die datum verloopt het contract met T-Mobile. Of de hotspots ook daarna nog gratis blijven, kan woordvoerder Eric Trinthamer van de NS nog niet zeggen.

nieuws: Treinreizigers verbruiken bijna 10TB via NS-hotspots

[.oisyn]

cpf_ schreef op dinsdag 17 juli 2012 @ 14:25:
[...]

Dikke grafiek?

Zoals ik al zei, FIFA Ultimate Team auctionhouse data. 850.000 records (dat is wat ik heb binnengehengeld, er zijn er nog veel meer) aan (al dan niet gelukte) trades van spelers en andere items.

De bedoeling is de marktwaarde van een item te bepalen en zo geautomatiseerd koopjes te spotten .

.edit: snelle analyse zegt dat er 185.682 spelers verkocht zijn binnen die tijdsperiode. De duurste was Christiano Ronaldo voor 1.528.000 coins.

[ Voor 28% gewijzigd door .oisyn op 17-07-2012 15:00 ]

[Korben]

Alex) schreef op dinsdag 17 juli 2012 @ 14:49:
.NET 3 en .NET 3.5 zijn gebouwd op de CLR van .NET 2.0. .NET 4.0 brengt een geheel nieuwe CLR met zich mee, en dat breekt backwards compatability helaas wel

Voor zover ik kan nagaan kun je Microsoft.SharePoint.dll niet inladen in een .NET 4.0-omgeving.

Ik heb zonder problemen DLL's voor CLR 2.0 gereferenced in mijn .NET 4.0-project, werkt als een zonnetje. In de machine.config van .NET 4.0 staan als het goed is zo'n beetje alle .NET 2.0 dll's geredirect naar hun 4.0-equivalenten.

Je moet wel zorgen dat je project gebuild wordt voor ".NET Framework 4.0", niet ".NET Framework 4.0 Client Profile", maar het zou moeten werken.

[BtM909]

Leuk he MS bashen

[Firesphere]

Alex) schreef op dinsdag 17 juli 2012 @ 14:51:
[...]


[...]


nieuws: Treinreizigers verbruiken bijna 10TB via NS-hotspots

Ah, grappig, laatste artikel dat ik had gelezen was dus het verhaal "uiterlijk 1 juli overal hotspots, per 1 januari betaald"
Als in, definitief per 1 januari 2013 betaald.
Maar daar zijn ze dus al weer wat minder definitief in geworden.

[Korben]

Lol, weer een mooie PHP fail: http://thedailywtf.com/Ar...ons-The-Phone-Number.aspx

Als je dus een nummer parset met PHP, maar dat nummer is groter dan een int, dan geeft PHP gewoon de maximale waarde van een int terug, in plaats van een foutmelding. Way to go.

[Patriot]

Korben schreef op dinsdag 17 juli 2012 @ 15:12:
Lol, weer een mooie PHP fail: http://thedailywtf.com/Ar...ons-The-Phone-Number.aspx

Als je dus een nummer parset cast met PHP, maar dat nummer is groter dan een int, dan geeft PHP gewoon de maximale waarde van een int terug, in plaats van een foutmelding. Way to go.

ftfy

[.oisyn]

Niet echt een hele grote WTF wmb. Het probleem is vooral dat men getallenreeksen in een int probeert op te slaan

[BM]

Alex) schreef op dinsdag 17 juli 2012 @ 14:49:
.NET 3 en .NET 3.5 zijn gebouwd op de CLR van .NET 2.0. .NET 4.0 brengt een geheel nieuwe CLR met zich mee, en dat breekt backwards compatability helaas wel

Voor zover ik kan nagaan kun je Microsoft.SharePoint.dll niet inladen in een .NET 4.0-omgeving.

code:

<startup useLegacyV2RuntimeActivationPolicy="true"/>

Helpt het als je dit in je config zet? Dat gebruiken wij hier om .Net 2.0 dll's in een 4.0 omgeving te gebruiken, en dat werkt prima

[Megamind]

Als je IIS gebruikt moet je ook iets daarin aanpassen om legacy 2.0 references te allowen in 32bit.

[ Voor 5% gewijzigd door Megamind op 17-07-2012 15:31 ]

[Robbiedobbie]

.oisyn schreef op dinsdag 17 juli 2012 @ 15:27:
Niet echt een hele grote WTF wmb. Het probleem is vooral dat men getallenreeksen in een int probeert op te slaan

Dat is ook niet slim om te doen, maar het punt is dat PHP minstens een warning zou moeten geven dat het getal out of range is, en niet zomaar de maximale waarde neer zou moeten zetten.

[Phoenix1337]

Probeer hetzelfde eens in MySQL zou ik zeggen.

[Cartman!]

Phoenix1337 schreef op dinsdag 17 juli 2012 @ 15:38:
Probeer hetzelfde eens in MySQL zou ik zeggen.

Daar krijg je netjes een warning ieder geval:

Warning: #1264 Out of range value adjusted for column 'foo' at row 1

PHP geeft helemaal geen waarschuwing, toch wel een verschil.

[Korben]

Cartman! schreef op dinsdag 17 juli 2012 @ 15:46:
[...]

Daar krijg je netjes een warning ieder geval:


[...]


PHP geeft helemaal geen waarschuwing, toch wel een verschil.

'Netjes'? Stel dat het om een account gaat waar je met echt geld 'credits' kunt kopen. Als je dan 2147483647 credits hebt, kun je voor duizenden euro's aan nieuwe credits kopen, maar je zult ze nooit opgehoogd zien worden, omdat MySQL 'netjes' de overflow 'corrigeert' en gewoon vrolijk doorgaat.

[Paul]

Ik zie juist dat PHP 'corrigeert en vrolijk doorgaat', MySQL 'geeft een warning'

Als je vervolgens niks met die warnings doet, tja

[F.West98]

Ik ben webdeveloping tijdelijk zat.
Dus nu ben ik me aan het richten op Android themes

[OkkE]

Erg vervelend dat de websites van onze klanten nog door 5% tot 10% met IE7 bezocht worden. Zou graag beginnen met box-sizing: border-box; te gebruiken.

[BtM909]

En waarom zou je het niet alvast gaan gebruiken en alleen lopen klooien met een IE7 conditional styling?

[Alex)]

Of bezoekers met IE 7 de vinger geven, omdat die browser inmiddels bijna 6 jaar oud is? Alternatieven zijn er genoeg: IE 8 en Chrome Frame.

[GateKeaper]

Ik heb een paar keer overwogen om het nut van NoSQL in te gaan zien, ik heb zelfs nog met RavenDB gespeeld en een testapp gemaakt. Maar toen ontdekte ik Entity Framework, en heb ik mezelf voorgenomen heel de database te "vergeten".

[Alex)]

GateKeaper schreef op dinsdag 17 juli 2012 @ 16:44:
Maar toen ontdekte ik Entity Framework, en heb ik mezelf voorgenomen heel de database te "vergeten".

Doe dat maar niet. Dat verdient een database niet.

Een database verdient liefde en aandacht.

[ Voor 88% gewijzigd door Alex) op 17-07-2012 16:46 ]

[Firesphere]

Alex) schreef op dinsdag 17 juli 2012 @ 16:44:
Of bezoekers met IE 7 de vinger geven, omdat die browser inmiddels bijna 6 jaar oud is? Alternatieven zijn er genoeg: IE 8 en Chrome Frame.

Helaas blijven veel, vooral grote, corporate bedrijven hangen in het verleden.
Leuk is dat. Ik heb ook zo'n opdrachtgever, maar moet dus o.a. dingen in facebook maken.
Raad eens? Facebook ondersteund zelf IE7 niet eens meer, dus dat mag ik elke keer weer uitleggen. Zucht.

[Verwijderd]

Klopt. Ik doe momenteel een vakantiejob bij Colruyt (grote warenhuisketen in Belgie) en hun in-house portaalsite moet via IE6 benadert worden. Om van te huilen.

[BM]

Alex) schreef op dinsdag 17 juli 2012 @ 16:45:
[...]

Doe dat maar niet. Dat verdient een database niet.

Een database verdient liefde en aandacht.

Dat vind ik prima, maar bij voorkeur niet van mij

Ik kan me best redden met sql, maar ik ben verder niet zo geinteresseerd in hoe de data opgeslagen word. Als ik er maar snel bij kan, en dat regelt EF opzich prima voor me

[Hydra]

Firesphere schreef op dinsdag 17 juli 2012 @ 16:48:
Helaas blijven veel, vooral grote, corporate bedrijven hangen in het verleden.

Niet omdat ze dat willen overigens, maar omdat er een legacy app is die iedereen gebruikt maar waar niemand nog de interne werking van snapt.

.oisyn schreef op dinsdag 17 juli 2012 @ 15:27:
Niet echt een hele grote WTF wmb. Het probleem is vooral dat men getallenreeksen in een int probeert op te slaan

PHP maakt er automagisch een INT van, dat is een van de problemen (niet in dat voorbeeld, maargoed). PHP is de oorzaak van m'n allergie voor dynamic typing. Gelukkig begin ik er mede danzij Python en JS een beetje van te genezen.

[ Voor 40% gewijzigd door Hydra op 17-07-2012 17:02 ]

[Megamind]

http://thekruser.com/2011/03/04/the-shredder/
Herkenbaar

[ytterx]

Megamind schreef op dinsdag 17 juli 2012 @ 16:55:
http://thekruser.com/2011/03/04/the-shredder/
Herkenbaar

Daarom begin ik altijd met de vraag "Wat wil je nou precies?". Voor je het weet doe je het fout..

[OkkE]

BtM909 schreef op dinsdag 17 juli 2012 @ 16:42:
En waarom zou je het niet alvast gaan gebruiken en alleen lopen klooien met een IE7 conditional styling?

Het zorgt er voor dat padding & border naar binnen berekend worden, ofwel, een div van 100 bij 100 pixels met een padding van 10 pixels en een border van 5 pixels, is ook 100x100 en niet 130x130.

Voorbeeldje: http://jsfiddle.net/okke/PzHmU/

Dat is zo'n groot verschilt tussen IE7 en de rest, als je daar voor een speciale CSS moet opzetten, waarbij je dus voor elk blok (hoogte en) breedte opnieuw moet instellen, kan je in mijn ogen beter voor alle browsers die CSS gebruiken.

Alex) schreef op dinsdag 17 juli 2012 @ 16:44:
Of bezoekers met IE 7 de vinger geven, omdat die browser inmiddels bijna 6 jaar oud is? Alternatieven zijn er genoeg: IE 8 en Chrome Frame.

Dat in IE(7) een input niet netjes uitlijnt met een button of een schaduwtje of subtiel verloop mist, dat is geen probleem.

Maar wanneer je mooie kolom-layout uit elkaar valt (laatste kolom volgende regel, etc), dat is net iets te veel verschil...

[BtM909]

Megamind schreef op dinsdag 17 juli 2012 @ 16:55:
http://thekruser.com/2011/03/04/the-shredder/
Herkenbaar

Ja

Na de hoeveelste shredder-actie kwam je erachter dat het niet zo handig is om maar blind te doen wat de CEO vraagt?

---

OkkE schreef op dinsdag 17 juli 2012 @ 17:05:
[...]

Het zorgt er voor dat padding & border naar binnen berekend worden, ofwel, een div van 100 bij 100 pixels met een padding van 10 pixels en een border van 5 pixels, is ook 100x100 en niet 130x130.

Maar wanneer je mooie kolom-layout uit elkaar valt (laatste kolom volgende regel, etc), dat is net iets te veel verschil...

Ehm, ik weet heus wel hoe het werkt

[ Voor 45% gewijzigd door BtM909 op 17-07-2012 17:06 ]

[Rutix]

^__^ de live meetings van http://live.aspconf.net/ werken nog best wel goed.

[Megamind]

BtM909 schreef op dinsdag 17 juli 2012 @ 17:05:
[...]

Ja

Na de hoeveelste shredder-actie kwam je erachter dat het niet zo handig is om maar blind te doen wat de CEO vraagt?

Ok, klant dan.

[OkkE]

BtM909 schreef op dinsdag 17 juli 2012 @ 17:05:
Ehm, ik weet heus wel hoe het werkt

Daar ging ik ook wel van uit, maar voor de volledigheid leg ik het toch gelijk even uit.

Ik weet niet hoeveel CSS jij nog doet in het dagelijks leven, maar ben je het niet met me eens dat het niet zo efficient is om voor IE7 een aparte CSS bij te houden wanneer het om zoiets belangrijks gaat als boders/padding wel of niet optellen?

[Soultaker]

Hydra schreef op dinsdag 17 juli 2012 @ 16:54:
PHP maakt er automagisch een INT van, dat is een van de problemen (niet in dat voorbeeld, maargoed).

PHP deed dat helemaal niet. Dat artikel is een voorbeeld waar de programmeur zelf de fout maakte; dat kan in elke taal gebeuren. Of elke taal met fixed-sized integers; in Python kun je natuurlijk wel arbitrair lange getallen naar int converteren, hoewel je dan nog steeds leading zeroes kwijtraakt, wat meestal niet de bedoeling is bij telefoonnummers.

PHP is de oorzaak van m'n allergie voor dynamic typing. Gelukkig begin ik er mede danzij Python en JS een beetje van te genezen.

Nee, JavaScript is lekker met z'n []+[]="", []+{}="[object Object]", {}+[]=0, {}+{}=NaN. Om maar te zwijgen over functies als parseInt() (wat denk je dat er gebeurt als je daar bijvoorbeeld een 06-nummer in gooit?)

Python doet dat beter. Van de bovenstaande is []+[]=[] en de rest is gewoon fout, net zoals dat int() geen basis probeert te raden, en een exception raiset de string niet in z'n geheel te converteren is. Er zijn in Python ook nog wel de nodige impliciete conversies (1 + True = 2) maar het feit dat strings en ints niet impliciet naar elkaar geconverteerd worden scheelt al een heleboel fouten, zonder significant aan kracht in te boeten.

(Er zijn ook nog wel wat problemen. In Python 2 is bijvoorbeeld None < 0, maar in Python 3 levert dat terecht een exception op.)

[ Voor 8% gewijzigd door Soultaker op 17-07-2012 17:14 ]

[Hydra]

Soultaker schreef op dinsdag 17 juli 2012 @ 17:13:
PHP deed dat helemaal niet. Dat artikel is een voorbeeld waar de programmeur zelf de fout maakte; dat kan in elke taal gebeuren. Of elke taal met fixed-sized integers; in Python kun je natuurlijk wel arbitrair lange getallen naar int converteren, hoewel je dan nog steeds leading zeroes kwijtraakt, wat meestal niet de bedoeling is bij telefoonnummers.

Ik zeg ook dat dat niet voor dat voorbeeld gold. Ik weet niet meer precies waar ik tegenaan gelopen ben (de laatste keer dat ik iets met PHP gedaan heb is 10 jaar geleden) maar ik weet nog goed dat 123 == "1234blaat" gewoon true is. Geen idee op welke plekken 't nog meer misgaat.

Python doet dat beter. Van de bovenstaande is []+[]=[] en de rest is gewoon fout, net zoals dat int() geen basis probeert te raden, en een exception raiset de string niet in z'n geheel te converteren is. Er zijn in Python ook nog wel de nodige impliciete conversies (1 + True = 2) maar het feit dat strings en ints niet impliciet naar elkaar geconverteerd worden scheelt al een heleboel fouten, zonder significant aan kracht in te boeten.

Dat is m'n punt dus. Dat in JS een hoop rare dingen zitten prima, maar PHP slaat wat dat betreft echt alles.

[NMe]

Hydra schreef op dinsdag 17 juli 2012 @ 17:17:
[...]

Ik zeg ook dat dat niet voor dat voorbeeld gold. Ik weet niet meer precies waar ik tegenaan gelopen ben (de laatste keer dat ik iets met PHP gedaan heb is 10 jaar geleden) maar ik weet nog goed dat 123 == "1234blaat" gewoon true is. Geen idee op welke plekken 't nog meer misgaat.

Aangenomen dat je daar een 4 vergeten bent of in de andere operand er een te veel getikt hebt: dat is misschien maf vergeleken met andere talen maar wel iets waar je op berekend kan zijn. Als je enige waarde hecht aan dat soort dingen schrijf je in PHP gewoon === in plaats van == en al je problemen op dit vlak zijn opgelost. Zo heeft elke taal wel iets vaags.

[Dido]

NMe schreef op dinsdag 17 juli 2012 @ 17:27:
Zo heeft elke taal wel iets vaags.

Try LANSA

Ik denk dat een hoop mensen van hun rants genezen als ze dat een tijdje proberen

[Barryvdh]

OkkE schreef op dinsdag 17 juli 2012 @ 17:10:
[...]

Daar ging ik ook wel van uit, maar voor de volledigheid leg ik het toch gelijk even uit.

Ik weet niet hoeveel CSS jij nog doet in het dagelijks leven, maar ben je het niet met me eens dat het niet zo efficient is om voor IE7 een aparte CSS bij te houden wanneer het om zoiets belangrijks gaat als boders/padding wel of niet optellen?

Ook niet de meeste mooie oplossing, maar je hebt er ook een polyfill voor: https://github.com/Schepp/box-sizing-polyfill
Natuurlijk wel minder efficiënt/snel/netjes en javascript nodig, maar dan moeten ze maar geen ie7 meer gebruiken

[azerty]

TheNephilim schreef op dinsdag 17 juli 2012 @ 13:41:

HTML:

<script type="text/javascript">document.write('<a href="mailto:');document.write('info');document.write('@');document.write('domein');document.write('.nl">');document.write('info');document.write('@');document.write('domein');document.write('.nl</a>');</script>

Je mag dat dan nog met javascript in de pagina zetten (zoals Davio eerder al zei is het denk ik inderdaad mogelijk om dat toch nog uit te lezen), maar vziw worden er toch lijsten gegenereerd met info@, webmaster@, ..., die mogen namelijk zonder voorafgaande toestemming in lijsten opgenomen worden om te verkopen (heb ik ooit eens ergens gelezen toch)

[Martijn19]

Alex) schreef op dinsdag 17 juli 2012 @ 16:44:
Of bezoekers met IE 7 de vinger geven, omdat die browser inmiddels bijna 6 jaar oud is? Alternatieven zijn er genoeg: IE 8 en Chrome Frame.

Inderdaad, ik begin er al niet meer. Zoek er maar een andere gek voor

[ValHallASW]

Soultaker schreef op dinsdag 17 juli 2012 @ 17:13:
Er zijn in Python ook nog wel de nodige impliciete conversies (1 + True = 2)

Dat is technisch gezien geen impliciete conversie - een bool is een int in python:

Python:

>>> isinstance(True, int)
True
>>> issubclass(bool, int)
True

(hoewel het natuurlijk wel een onverwachte 'is een' kan zijn)

Dé impliciete conversie in python die schadelijk is, is die tussen str en unicode - die worden met 'een' standaardencoding (normaal ASCII) in elkaar omgezet, wat nog wel eens gekke dingen wil opleveren (data.decode('utf-8') die een UnicodeEncodeError geeft). Die impliciete conversie is er in Python 3 gelukkig uitgegooid.

[ Voor 5% gewijzigd door ValHallASW op 17-07-2012 19:37 ]

[Firesphere]

ValHallASW schreef op dinsdag 17 juli 2012 @ 19:31:
[...]

Dat is technisch gezien geen impliciete conversie - een bool is een int in python:

Python:

>>> isinstance(True, int)
True
>>> issubclass(bool, int)
True

(hoewel het natuurlijk wel een onverwachte 'is een' kan zijn)

Dé impliciete conversie in python die schadelijk is, is die tussen str en unicode - die worden met 'een' standaardencoding (normaal ASCII) in elkaar omgezet, wat nog wel eens gekke dingen wil opleveren (data.decode('utf-8') die een UnicodeEncodeError geeft). Die impliciete conversie is er in Python 3 gelukkig uitgegooid.

Ik gebruik eigenlijk altijd een int(1) in m'n databases als boolean settings.

[Soundless]

Firesphere schreef op dinsdag 17 juli 2012 @ 19:38:
[...]

Ik gebruik eigenlijk altijd een int(1) in m'n databases als boolean settings.

Daar heb je in MySQL toch tinyint voor..
int(1) is afaik nog steeds een 32 bits integer. Afaik had het getal tussen () alleen te maken met de voorloopnullen en dat alleen met 1 specifiek db engine (weet even niet meer welke).

[.oisyn]

Robbiedobbie schreef op dinsdag 17 juli 2012 @ 15:32:
[...]

Dat is ook niet slim om te doen, maar het punt is dat PHP minstens een warning zou moeten geven dat het getal out of range is, en niet zomaar de maximale waarde neer zou moeten zetten.

Alsof je in een andere taal wel een warning krijgt als je bijv. een te grote double naar een int cast. Zo'n warning is in PHP ook absoluut niet wat je wilt, die wordt namelijk aan de gebruiker getoond ipv dat je applicatie erop in kan spelen.

[Firesphere]

Soundless schreef op dinsdag 17 juli 2012 @ 19:51:
[...]

Daar heb je in MySQL toch tinyint voor..
int(1) is afaik nog steeds een 32 bits integer. Afaik had het getal tussen () alleen te maken met de voorloopnullen en dat alleen met 1 specifiek db engine (weet even niet meer welke).

Sorry, tinyint inderdaad, maar you get the drift toch. Dacht dat MyISAM standaard netjes de int-length op 1 zet trouwens, maar weet't ook niet helemaal zeker.

[Soultaker]

ValHallASW schreef op dinsdag 17 juli 2012 @ 19:31:
Dat is technisch gezien geen impliciete conversie - een bool is een int in python

Ah, dat wist ik niet eens!

[Cartman!]

.oisyn schreef op dinsdag 17 juli 2012 @ 19:56:
Alsof je in een andere taal wel een warning krijgt als je bijv. een te grote double naar een int cast. Zo'n warning is in PHP ook absoluut niet wat je wilt, die wordt namelijk aan de gebruiker getoond ipv dat je applicatie erop in kan spelen.

Je zou sowieso in productie-omgevingen nooit warnings (of zelfs notices) moeten zien dus dat is geen argument imo. Ik zou het wel prettig vinden als PHP er een warning op zou geven.

[CodeCaster]

.oisyn schreef op dinsdag 17 juli 2012 @ 19:56:
[...]


Alsof je in een andere taal wel een warning krijgt als je bijv. een te grote double naar een int cast.

Dat kan. Maar nee, niet standaard.

[ Voor 4% gewijzigd door CodeCaster op 17-07-2012 21:43 ]

[NMe]

Cartman! schreef op dinsdag 17 juli 2012 @ 21:05:
[...]

Je zou sowieso in productie-omgevingen nooit warnings (of zelfs notices) moeten zien dus dat is geen argument imo. Ik zou het wel prettig vinden als PHP er een warning op zou geven.

Geen warning, hooguit een notice. En eigenlijk hoor je als developer natuurlijk wel de bijzondere getallen te kunnen herkennen. Machten van 2 tot een bepaald praktisch punt, en vooral 2,14 miljard en de unsigned variant daarop zouden een belletje moeten laten rinkelen.

_{Wat niet betekent dat ik er zelf niet wel eens een fout tegen heb gemaakt.}

[Patriot]

NMe schreef op dinsdag 17 juli 2012 @ 22:14:
[...]

Geen warning, hooguit een notice. En eigenlijk hoor je als developer natuurlijk wel de bijzondere getallen te kunnen herkennen. Machten van 2 tot een bepaald praktisch punt, en vooral 2,14 miljard en de unsigned variant daarop zouden een belletje moeten laten rinkelen.

_{Wat niet betekent dat ik er zelf niet wel eens een fout tegen heb gemaakt.}

Dat ging in het verhaal op TDWTF vooral mis omdat "214" zeer normaal was voor een telefoonnummer om mee te beginnen. Daar is "2147483647" gewoon een geldig telefoonnummer. Als daar vervolgens streepjes tussen staan en 214 is het "netnummer" (weet niet hoe je dat daar noemt) voor jouw omgeving dan kijk ik er niet van op als je niet meteen beseft dat het de maximale waarde van een 32-bits integer is.

[Cartman!]

NMe schreef op dinsdag 17 juli 2012 @ 22:14:
[...]
_{Wat niet betekent dat ik er zelf niet wel eens een fout tegen heb gemaakt.}

Same here, toen Facebook ineens zijn userId's begon te prefixen met 100000

[Phoenix1337]

Je zou ook nog een bit kunnen gebruiken voor een boolean veld in de database ?

[BM]

Net toch Aero maar enabled op mijn Win 2008R2 dev bak. Mistte Aero-peek toch wel aardig eigenlijk

[Phoenix1337]

Nu we het net over de MAX_INT hebben. Ik kijk in de database want een script werkt niet meer. Blijkt een externe partij hun CSV-bestand aangepast te hebben waardoor een kolom want geen int is nu als int ingelezen werd en de waarde 2147483647 aan de database toevoegt.

Natuurlijk is het bestand aangepast zonder dat dit verteld is.

[Hydra]

Dat een string aan jouw kant als int gelezen wordt is toch echt niet hun fout.

NMe schreef op dinsdag 17 juli 2012 @ 17:27:
[...]

Aangenomen dat je daar een 4 vergeten bent of in de andere operand er een te veel getikt hebt: dat is misschien maf vergeleken met andere talen maar wel iets waar je op berekend kan zijn. Als je enige waarde hecht aan dat soort dingen schrijf je in PHP gewoon === in plaats van == en al je problemen op dit vlak zijn opgelost. Zo heeft elke taal wel iets vaags.

Een 4 teveel idd. Ik vind het niet 'iets vaags', ik vind het een dom 'handigheidje' dat voor enorm veel problemen zorgt. Dergelijke impliciete casts zijn ranzig IMHO.

[ Voor 80% gewijzigd door Hydra op 18-07-2012 09:31 ]

[Phoenix1337]

Misschien dat ik t verkeerd zeg: op index 2 stond normaal gesproken een getal waarmee ik een bestelling bij ons kan identificeren. Alleen omdat ze op index 1 een extra kolom toegevoegd hebben werd hun identificatienummer (wat geen int is maar een tekenreeks uit alleen getallen) bij ons als int ingelezen.

[Cartman!]

Hydra schreef op woensdag 18 juli 2012 @ 09:29:
Een 4 teveel idd. Ik vind het niet 'iets vaags', ik vind het een dom 'handigheidje' dat voor enorm veel problemen zorgt. Dergelijke impliciete casts zijn ranzig IMHO.

Wat voor real life problemen heeft je dat opgeleverd dan? Ik kan me niet herinneren dat ik daar ooit last van gehad heb in de praktijk.

In php zit er wel een optie in json_decode die JSON_BIGINT_AS_STRING heet die simpelweg quotes zet om te grote getallen zodat het als string gecast wordt. Toen dat er nog niet was moest ik dat zelf met een scriptje eerst aanpassen omdat Twitter toen nog geen "id_str" meestuurde.

[ Voor 25% gewijzigd door Cartman! op 18-07-2012 09:50 ]

[.oisyn]

Het gaat vooral fout als je denkt "ik vergelijk 2 strings, dus ik kan best == gebruiken", wat ook niet waar is. "10000000000000000" == "10000000000000001" => true

[ Voor 3% gewijzigd door .oisyn op 18-07-2012 10:15 ]

[Korben]

.oisyn schreef op woensdag 18 juli 2012 @ 10:14:
Het gaat vooral fout als je denkt "ik vergelijk 2 strings, dus ik kan best == gebruiken", wat ook niet waar is. "10000000000000000" == "10000000000000001" => true

Is het dan ook niet zo dat:

PHP:

(int) 10000000000000000 == (int) 10000000000000001 // true?

[D-Raven]

Zit even naar asp.net single page application te kijken.. Holy... anders gooi je er even een beetje javascript tegenaan...

Ook nog maar magere documentatie overigens. Her en der wat blogpostjes, thats it.

* D-Raven hoort voor t eerst over upshot.js
Heb ook nog 0 ervaring met knockout.js, mja heb er van een afstand naar gekeken, maar meer ook nog niet

[Hydra]

Cartman! schreef op woensdag 18 juli 2012 @ 09:46:
Wat voor real life problemen heeft je dat opgeleverd dan?

Dat kan ik me na 10 jaar niet meer herinneren sorry, ik doe niks meer met PHP, gelukkig.

[.oisyn]

Korben schreef op woensdag 18 juli 2012 @ 10:17:
[...]

Is het dan ook niet zo dat:

PHP:

(int) 10000000000000000 == (int) 10000000000000001 // true?

Ze worden geconvert naar float. Het antwoord op je vraag is overigens ja, maar wat is je punt? Als ik twee strings vergelijk, waarom wil ie dan überhaupt kijken of ze te converten zijn naar een getal? Dat ie dat doet als je een string met een getal vergelijkt snap ik (al doet ie dat ook niet goed, om de bekende reden)

[ Voor 36% gewijzigd door .oisyn op 18-07-2012 10:40 ]

[Cartman!]

Hydra schreef op woensdag 18 juli 2012 @ 10:33:
Dat kan ik me na 10 jaar niet meer herinneren sorry, ik doe niks meer met PHP, gelukkig.

Dan zal het wel meevallen dus.

[Jan_V]

D-Raven schreef op woensdag 18 juli 2012 @ 10:18:
Zit even naar asp.net single page application te kijken.. Holy... anders gooi je er even een beetje javascript tegenaan...

Ook nog maar magere documentatie overigens. Her en der wat blogpostjes, thats it.

* D-Raven hoort voor t eerst over upshot.js
Heb ook nog 0 ervaring met knockout.js, mja heb er van een afstand naar gekeken, maar meer ook nog niet

Oh, is dat inmiddels final? Dacht dat ze het pas ergens in de winter zouden uitgeven.
Zal idd een bak vol JS zijn, anders kan het natuurlijk ook niet. Zit knockout er in geintegreerd dan, of gewoon een losse side-note.

[Korben]

.oisyn schreef op woensdag 18 juli 2012 @ 10:37:
[...]

Ze worden geconvert naar float. Het antwoord op je vraag is overigens ja, maar wat is je punt? Als ik twee strings vergelijk, waarom wil ie dan überhaupt kijken of ze te converten zijn naar een getal? Dat ie dat doet als je een string met een getal vergelijkt snap ik (al doet ie dat ook niet goed, om de bekende reden)

Mijn punt is dat het ontzettend fail is dat nummers zomaar worden 'gecorrigeerd'. Die code zou moeten falen met een overflow-error of exception.

[.oisyn]

In dat geval wel ja. Maar bij conversie naar float is er geen overflow.
Saillant detail: (int)10000000000000000 => 1874919424 . Blijkbaar wordt 10000000000000000 dus eerst geconvert naar een 64 bits int.

.edit: ik zie dat MSVC++ dezelfde quirk heeft.

[ Voor 65% gewijzigd door .oisyn op 18-07-2012 11:12 ]

[OkkE]

Geloof dat dit niet allemaal advertenties zijn waar Shell op zit te wachten:
http://arcticready.com/social/gallery

[ Voor 7% gewijzigd door OkkE op 18-07-2012 11:08 ]

[Phoenix1337]

Voor het eerst in mn leven een xsd geschreven die ik ook echt gebruik

[TheNephilim]

OkkE schreef op woensdag 18 juli 2012 @ 11:07:
Geloof dat dit niet allemaal advertenties zijn waar Shell op zit te wachten:
http://arcticready.com/social/gallery

Haha, geniaal

[.oisyn]

OkkE schreef op woensdag 18 juli 2012 @ 11:07:
Geloof dat dit niet allemaal advertenties zijn waar Shell op zit te wachten:
http://arcticready.com/social/gallery

Je snapt hopelijk dat die site niet van Shell zelf is, he?

[Ook al Bezet]

OkkE schreef op woensdag 18 juli 2012 @ 11:07:
Geloof dat dit niet allemaal advertenties zijn waar Shell op zit te wachten:
http://arcticready.com/social/gallery

Met zo'n campagne vraag je ook gewoon om problemen, ik denk dat er bij de marketingafdeling toch wat koppen gaan rollen

EDIT: @.oisyn, ah, jammer, was ook te mooi om waar te zijn.

[ Voor 8% gewijzigd door Ook al Bezet op 18-07-2012 11:19 ]

[Korben]

Ook al Bezet schreef op woensdag 18 juli 2012 @ 11:18:
[...]

Met zo'n campagne vraag je ook gewoon om problemen, ik denk dat er bij de marketingafdeling toch wat koppen gaan rollen

EDIT: @.oisyn, ah, jammer, was ook te mooi om waar te zijn.

Wel gedurfd, het Shell-logo gebruiken en je voor doen als Shell. Ik denk dat er in de rechtszaal wat koppen gaan rollen.

[Laurens-R]

Als je denkt dat die site echt van Shell is, zie je de activistische ondertoon er achter niet echt

[.oisyn]

Inderdaad:

[q]Right now, the polar ice caps of our planet are melting.

That's bad—but it's also good!

That's right! It's bad because our planet needs ice at the poles. But it's good because when the polar ice melts, we at Shell can go up there to get more oil, which can do a whole lot of things. Thanks to oil:

• Mommy and Daddy can drive to the store to buy you new toys.
• Companies like Mattel™ can build new toys.
• Engineers can drive to work to design new, better toys that are even more fun to play with.
• When you're done with your toys, trucks can take them away to dispose of.

Oil can even help us fix some of the problems that melting ice causes.

So it's fine to be sad about our melting polar ice caps, and about how sad that makes the planet—but remember to be glad as well, because of all that the oil we're finding there is letting you do, now and far into the future!

[.oisyn]

Lol Greenpeace en The Yes Men zitten erachter
http://www.greenpeace.org...ory-o/blog/40893/?ilink=1

[ Voor 62% gewijzigd door .oisyn op 18-07-2012 11:24 ]

[OkkE]

.oisyn schreef op woensdag 18 juli 2012 @ 11:16:
[...]

Je snapt hopelijk dat die site niet van Shell zelf is, he?

Dat was mij duidelijk ja.

Neemt niet weg dat het een redelijk succesvolle stunt is en ik erg benieuwd ben naar hoe dit gaat aflopen.

.oisyn schreef op woensdag 18 juli 2012 @ 11:23:
Lol Greenpeace en The Yes Men zitten erachter
http://www.greenpeace.org...ory-o/blog/40893/?ilink=1

Daar zit nog best wel een werk achter, zo te lezen.

[ Voor 35% gewijzigd door OkkE op 18-07-2012 11:36 ]

[Alex)]

En toen was productie stuk. Oeps!

[ Voor 130% gewijzigd door Alex) op 18-07-2012 11:44 ]

[D-Raven]

Jan_V schreef op woensdag 18 juli 2012 @ 10:48:
[...]

Oh, is dat inmiddels final? Dacht dat ze het pas ergens in de winter zouden uitgeven.
Zal idd een bak vol JS zijn, anders kan het natuurlijk ook niet. Zit knockout er in geintegreerd dan, of gewoon een losse side-note.

Geen idee. Ik liep hier tegenaan: http://channel9.msdn.com/...erlands/2159?format=html5

Maar het is best wel gaaf. Upshot zorgt voor de lijm tussen WebAPI (welke je model aanlevert vanuit de DB) en Knockout.

Je gebruikt Upshot als je ViewModel welke de data uit je WebAPI endpoint trekt, en deze mapped naar knockout.js. Vervolgens werkt het ook automatisch de andere kant op, dus als je clientside een wijziging in je data maakt, dan wordt je knockout view geupdate, welke door Upshot meteen gesynced word naar je WebAPI endpoint. Wat overigens ook weer getweaked kan worden.

Hoe lastig zou t zijn om Upshot aan een SignalR datasource kan koppelen?

[.oisyn]

Jeej m'n Raspberry Pi is geshipt \o/

[Rutix]

.oisyn schreef op woensdag 18 juli 2012 @ 12:31:
Jeej m'n Raspberry Pi is geshipt \o/

Waar had je hem besteld?

[alienfruit]

Ja, mijne ook... alleen nog niet aangekomen Adres klopt ook niet terwijl ik het wel goed heb ingevuld

[Alex)]

Alex) schreef op woensdag 18 juli 2012 @ 11:42:
En toen was productie stuk. Oeps!

[afbeelding]

Vaag, op mijn dev-omgeving werkt het allemaal naar behoren. Mijn vermoeden is een fout bij deployment

[.oisyn]

Rutix schreef op woensdag 18 juli 2012 @ 12:38:
[...]

Waar had je hem besteld?

BIJ JE MOEDER!!

Element 14 van Farnell. Wel wat aan de prijzige kant though, 32 Britse pond. Anyway, mainland Europe was 3 tot 5 werkdagen shipping

[ Voor 10% gewijzigd door .oisyn op 18-07-2012 13:19 ]

[Styxxy]

.oisyn schreef op woensdag 18 juli 2012 @ 13:18:
[...]
Wel wat aan de prijzige kant though, 32 Britse pond.

32 pond is prijzig? Ach, Nederlanders...

[.oisyn]

Ja, 32 pond ligt boven de marktwaarde en dus is het een minder goede deal. Of kijk jij altijd alleen naar absolute getallen?

[ Voor 16% gewijzigd door .oisyn op 18-07-2012 13:21 ]

[GateKeaper]

Pfff... is 't al bijna weekend?

[Laurens-R]

Alex) schreef op woensdag 18 juli 2012 @ 13:15:
[...]

Vaag, op mijn dev-omgeving werkt het allemaal naar behoren. Mijn vermoeden is een fout bij deployment

Of wat mij wel eens overkomt: dat het verschil in server setup verschillend is. PRD is meestal multi-server vanwege loadbalancing etc en dat kan zich wel eens anders gedragen dan een single server farm in DEV. (zeker ivm rechten etc).

[Dido]

En nummer dire is binnen (70-513). Kantje-boord maar binnen is binnen.
Nog 70-519 te gaan. Daarna kan ik eindelijk slapen

[Down]

Dido schreef op woensdag 18 juli 2012 @ 13:50:
En nummer dire is binnen (70-513). Kantje-boord maar binnen is binnen.
Nog 70-519 te gaan. Daarna kan ik eindelijk slapen

Netjes . Ik ga 70-513 volgende week doen. Moet me zelf soms alleen wel motiveren, want WCF heeft zo belachelijk veel opties waarvan de helft me niet interesseert

[Soundless]

Dido schreef op woensdag 18 juli 2012 @ 13:50:
En nummer dire is binnen (70-513). Kantje-boord maar binnen is binnen.
Nog 70-519 te gaan. Daarna kan ik eindelijk slapen

Gratz. Ik hoop (zsm) ook nog eens te beginnen met het behalen van wat certificaten.

[Dido]

Down schreef op woensdag 18 juli 2012 @ 14:25:
Netjes . Ik ga 70-513 volgende week doen. Moet me zelf soms alleen wel motiveren, want WCF heeft zo belachelijk veel opties waarvan de helft me niet interesseert

Herkenbaar. En ik moet zeggen dat ie me toch ook inderdad wel een beetje tegenviel
maar goed, binnen is binnen en op naar m'n MCPD

Soundless schreef op woensdag 18 juli 2012 @ 14:36:
Gratz. Ik hoop (zsm) ook nog eens te beginnen met het behalen van wat certificaten.

tnx Moet zeggen dat India me voorlopig uistekend bevalt om dat te doen

[OkkE]

GateKeaper schreef op woensdag 18 juli 2012 @ 13:33:
Pfff... is 't al bijna weekend?

Als ik er van uit mag gaan dat jouw weekend op vrijdag om 17:00 begint en in deze context de definitie van "bijna" minder is dan 2+ dagen: nee, het is niet "al bijna weekend".

Of anders een simpelere aanpak: http://www.fanvanhetweekend.be/

[Rutix]

.oisyn schreef op woensdag 18 juli 2012 @ 13:18:
[...]

BIJ JE MOEDER!!

Element 14 van Farnell. Wel wat aan de prijzige kant though, 32 Britse pond. Anyway, mainland Europe was 3 tot 5 werkdagen shipping

Had me moeder ze maar :<

[Korben]

FML, ik moet nou een SOAP-webservice gaan slopen zodat het geen SOAP-webservice meer is, maar de input met regexen wordt geparset, omdat schijnbaar sommige gebruikers niet in staat zijn fatsoenlijke SOAP te construeren, of zelfs fatsoenlijke XML te bouwen.

[Sardaukar]

Doet me denken aan die klant waarvan management aangaf dat ze nu met de externe partijen via XML wilden communiceren. Later moest ik aan hun eigen ICT'ers gaan uitleggen wat XML was en hoe ze het moesten gaan aanleveren