[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

Om nog maar even door te gaan op mac-adressen

Er zijn nog steeds mensen die vertrouwen op het mac-adres voor beveiliging. Ik was laatst op een camping waar een wifi-spot zat(dit was geïnstalleerd) door een bedrijf. Hier kon je een abbo kopen voor een week(username, ww). Maar wanneer die eenmaal waren ingevoerd sloeg de server het mac-adres op en kon je zo internetten, alleen niet met 2 pc's. Even een mac-spoof en je kunt op twee pc's internetten, altijd leuk

[Davio]

Wat dat betreft kun je MAC-adressen in de praktijk dus een slecht programmeervoorbeeld noemen en zijn we juist heel erg on-topic.

[.oisyn]

Verwijderd schreef op donderdag 05 augustus 2010 @ 15:00:
Om nog maar even door te gaan op mac-adressen

Er zijn nog steeds mensen die vertrouwen op het mac-adres voor beveiliging. Ik was laatst op een camping waar een wifi-spot zat(dit was geïnstalleerd) door een bedrijf. Hier kon je een abbo kopen voor een week(username, ww). Maar wanneer die eenmaal waren ingevoerd sloeg de server het mac-adres op en kon je zo internetten, alleen niet met 2 pc's. Even een mac-spoof en je kunt op twee pc's internetten, altijd leuk

En als je verbond met het netwerk en wilde browsen kwam je zeker op een landing page waar je je naam + wachtwoord in moet vullen? Met andere woorden, vaak compleet onbeveiligd dus je kunt ook wel de MAC adressen van je mede-kampeerders uit de lucht trekken

[CoolGamer]

.oisyn schreef op donderdag 05 augustus 2010 @ 15:27:
[...]

En als je verbond met het netwerk en wilde browsen kwam je zeker op een landing page waar je je naam + wachtwoord in moet vullen? Met andere woorden, vaak compleet onbeveiligd dus je kunt ook wel de MAC adressen van je mede-kampeerders uit de lucht trekken

Nog een ARP-spoofje erbij en je hebt ook gelijk de wachtwoorden van gebruikers. Kan je de volgende keer zelf inloggen.

[bobo1on1]

Verwijderd schreef op donderdag 05 augustus 2010 @ 15:00:
Om nog maar even door te gaan op mac-adressen

Er zijn nog steeds mensen die vertrouwen op het mac-adres voor beveiliging. Ik was laatst op een camping waar een wifi-spot zat(dit was geïnstalleerd) door een bedrijf. Hier kon je een abbo kopen voor een week(username, ww). Maar wanneer die eenmaal waren ingevoerd sloeg de server het mac-adres op en kon je zo internetten, alleen niet met 2 pc's. Even een mac-spoof en je kunt op twee pc's internetten, altijd leuk

Mja, maar je kunt nog steeds maar met een pc tegelijk het internet op.

[ Voor 81% gewijzigd door bobo1on1 op 05-08-2010 15:36 ]

[Boudewijn]

MAC spoof op hetzelfde netwerk is niet handig. Je kunt dan beter gewoon de ene pc als router inzetten .

[Noxious]

Verwijderd schreef op donderdag 05 augustus 2010 @ 15:00:
Om nog maar even door te gaan op mac-adressen

Er zijn nog steeds mensen die vertrouwen op het mac-adres voor beveiliging. Ik was laatst op een camping waar een wifi-spot zat(dit was geïnstalleerd) door een bedrijf. Hier kon je een abbo kopen voor een week(username, ww). Maar wanneer die eenmaal waren ingevoerd sloeg de server het mac-adres op en kon je zo internetten, alleen niet met 2 pc's. Even een mac-spoof en je kunt op twee pc's internetten, altijd leuk

Oftewel, even sniffen naar iemand die wel betaald heeft en hoppa

[Boudewijn]

Voor dat soort dingen gebruik liever IP over DNS . DNS staat vaak open op hotspots om zo URLs te kunnen resolven.
Je eigen DNS server gebruiken en tunnelen maar .

[Verwijderd]

.oisyn schreef op donderdag 05 augustus 2010 @ 15:27:
[...]

En als je verbond met het netwerk en wilde browsen kwam je zeker op een landing page waar je je naam + wachtwoord in moet vullen? Met andere woorden, vaak compleet onbeveiligd dus je kunt ook wel de MAC adressen van je mede-kampeerders uit de lucht trekken

Ja klopt En ik weet de naam van het bedrijf helaas niet meer want die stond eronder. Maar als ik er volgend jaar weer sta ga ik ff kijken of ik wat rondvliegende pakkten op kan vangen

Tis trouwens ook pokkeduur dat wifi daar, 13,50 per week. Daar kun je in in Afrika een heel land van kopen

[Verwijderd]

Boudewijn schreef op donderdag 05 augustus 2010 @ 15:39:
MAC spoof op hetzelfde netwerk is niet handig. Je kunt dan beter gewoon de ene pc als router inzetten .

Was ook mijn eerste idee, maar ik had mijn laptop niet mee, en mijn kennisen vertrouwen mij niet helemaal met hun laptops. Bang dat ik hem brick

[m-m]

DNS tunneling is alleen wel traaaaag

[Woy]

Zo kunnen we nu weer een beetje on-topic gaan.

[Verwijderd]

Ik zal maar ontopic gaan dan.

Ik heb een tijdje gewerkt bij een klein bedrijfje. Hier hadden we een 'lead developer', hiervan mag je normaliter verwachten dat hij z'n zaakjes op orde heeft en zulke dingen echt níet doet:

PHP:

$pdo->query('SELECT id, something FROM aTable WHERE foo = "'.$_GET['bar'].'";');

Maar volgens hem was het geen SQL-injectie, omdat er PDO gebruikt werd. Ook na een simpele demonstratie was hij er stellig van overtuigd dat het geen SQL-injectie is.

[Alex)]

Lang leve parameterized queries, meer kan ik er niet op zeggen.

Oh, toch.wel: wat één n00b is dat dan...

[dragontje124]

Verwijderd schreef op donderdag 05 augustus 2010 @ 19:24:
Ik zal maar ontopic gaan dan.

Ik heb een tijdje gewerkt bij een klein bedrijfje. Hier hadden we een 'lead developer', hiervan mag je normaliter verwachten dat hij z'n zaakjes op orde heeft en zulke dingen echt níet doet:

PHP:

$pdo->query('SELECT id, something FROM aTable WHERE foo = "'.$_GET['bar'].'";');

Maar volgens hem was het geen SQL-injectie, omdat er PDO gebruikt werd. Ook na een simpele demonstratie was hij er stellig van overtuigd dat het geen SQL-injectie is.

gewoon

SQL:

TRUNCATE TABLE aTable;

injecten, dan leert ie het wel af

[YopY]

Typisch klok/klepel geval, zoals heeeel erg vaak voor lijkt te komen.

[CoolGamer]

Misschien had hij Magic Quotes aanstaan.

Oh, nee dan was je demo niet gelukt

[Verwijderd]

TheCoolGamer schreef op donderdag 05 augustus 2010 @ 21:37:
Misschien had hij Magic Quotes aanstaan.

Oh, nee dan was je demo niet gelukt

Ja ik heb er ook eens jongens in projecten op aangesproken maar deze zeiden, magic_quotes staat aan ja....

[MueR]

Oh gaaf, met dat soort volk zou ik een field day hebben

[NederB]

Mooi voor beveiligde pagina's

JavaScript:

<script language="JavaScript" type="text/javascript">
  var password = prompt("Uw wachtwoord a.u.b.:","");

  switch(password){
  case"wachtwoord" : window.location="javascript:correct()"
  break ; 

  default : window.location="javascript:error()"
  break ; 
  } 

</script>

[.oisyn]

En ook javascript functies aanroepen door window.location in te stellen

[Davio]

NederB schreef op vrijdag 06 augustus 2010 @ 00:20:
Mooi voor beveiligde pagina's

JavaScript:

<script language="JavaScript" type="text/javascript">
  var password = prompt("Uw wachtwoord a.u.b.:","");

  switch(password){
  case"wachtwoord" : window.location="javascript:correct()"
  break ; 

  default : window.location="javascript:error()"
  break ; 
  } 

</script>

Hihi, zoiets kom je in lvl 3 van 'Trytohack' al tegen ofzo.

[Lulukai]

Ik ken 0 JavaScript, maar wat is daar precies verkeerd aan?

[kwaakvaak_v2]

ruyckske schreef op vrijdag 06 augustus 2010 @ 09:21:
Ik ken 0 JavaScript, maar wat is daar precies verkeerd aan?

wel... het wachtwoord is dus ehh wachtwoord

Zie die case"wachtwoord"

[Voutloos]

@ruyckske : Wellicht handig om dan eerst wat op te zoeken, want als devvert mag je eigenlijk wel weten wat het is.

kwaakvaak_v2 schreef op vrijdag 06 augustus 2010 @ 09:25:
[...]


wel... het wachtwoord is dus ehh wachtwoord

Zie die case"wachtwoord"

Geldt ook voor jou. Een beter wachtwoord had echt niet geholpen.

[ Voor 57% gewijzigd door Voutloos op 06-08-2010 09:27 ]

[Reptile209]

ruyckske schreef op vrijdag 06 augustus 2010 @ 09:21:
Ik ken 0 JavaScript, maar wat is daar precies verkeerd aan?

Dat het 'wachtwoord' letterlijk in de broncode van de pagina staat .

offtopic:
Damn, 3 binnen één minuut...

[ Voor 8% gewijzigd door Reptile209 op 06-08-2010 09:26 ]

[Amras]

kwaakvaak_v2 schreef op vrijdag 06 augustus 2010 @ 09:25:
[...]


wel... het wachtwoord is dus ehh wachtwoord

Zie die case"wachtwoord"

Maar dat verwacht toch niemand?

[rmpel]

Hier probeerde een van mijn voorgangers de laatste regel in een log op te halen;

PHP:

  $result = mysql_query("SELECT * FROM log ORDER BY autonr DESC");
  $first_row = true;
  while ($row = mysql_fetch_array($result)) {
    if ($first_row) {
      $last_line = $row;
    }
    $first_row = false;
  }

En dan klagen dat het met ruim 5 miljoen regels in de log de pagina zo langzaam is

[roy-t]

rmpel schreef op vrijdag 06 augustus 2010 @ 09:30:
Hier probeerde een van mijn voorgangers de laatste regel in een log op te halen;

PHP:

  $result = mysql_query("SELECT * FROM log ORDER BY autonr DESC");
  $first_row = true;
  while ($row = mysql_fetch_array($result)) {
    if ($first_row) {
      $last_line = $row;
    }
    $first_row = false;
  }

En dan klagen dat het met ruim 5 miljoen regels in de log de pagina zo langzaam is

Dat snap ik dan niet als je "SELECT * FROM log ORDER BY autonr DESC" kunt bedenken, dan kun je toch ook wel bedenken er Limit 1 achter te zetten?

[rmpel]

roy-t schreef op vrijdag 06 augustus 2010 @ 09:44:
Dat snap ik dan niet als je "SELECT * FROM log ORDER BY autonr DESC" kunt bedenken, dan kun je toch ook wel bedenken er Limit 1 achter te zetten?

exact! Dat was dus ook mijn fix om de pagina in 0.5 sec te laten laden ipv 10 sec.

De database staat remote over druk bezette en trage verbinding, dus elke seconde telt, laat staan 10

[Dracoo]

Je hebt ook de loop eruit gesloopt hoop ik?

edit:
quote verwijderd

[ Voor 102% gewijzigd door Dracoo op 06-08-2010 10:02 ]

[TJHeuvel]

Als je dan zo graag het in een while-lus doet break dan gewoon na de eerste keer

[ZpAz]

.oisyn schreef op vrijdag 06 augustus 2010 @ 00:25:
En ook javascript functies aanroepen door window.location in te stellen

Nou idd, ik weet niet wat 'erger is'.

[Lulukai]

rmpel schreef op vrijdag 06 augustus 2010 @ 09:30:
Hier probeerde een van mijn voorgangers de laatste regel in een log op te halen;

PHP:

  $result = mysql_query("SELECT * FROM log ORDER BY autonr DESC");
  $first_row = true;
  while ($row = mysql_fetch_array($result)) {
    if ($first_row) {
      $last_line = $row;
    }
    $first_row = false;
  }

En dan klagen dat het met ruim 5 miljoen regels in de log de pagina zo langzaam is

PHP:

$result = mysql_query("SELECT * FROM log ORDER BY autonr DESC");
$row = mysql_fetch_array($result));

of

PHP:

$row = mysql_query("SELECT * FROM log ORDER BY autonr DESC LIMIT 0,1");

Neem ik aan?

Worden dan niet nog altijd de 5 miljoen dingen ingeladen? Kan dit niet nog efficiënter?

[ Voor 7% gewijzigd door Lulukai op 06-08-2010 10:08 . Reden: syntax fixed ]

[TJHeuvel]

Bij de eerste krijg je uiteraard een syntax error
Bovendien is het gebruik van LIMIT als je het aantal record-sets wilt limiteren aangeraden, en SELECT * meestal langzamer dan individueel de velden aangeven.

[ Voor 20% gewijzigd door TJHeuvel op 06-08-2010 10:07 ]

[Verwijderd]

Davio schreef op vrijdag 06 augustus 2010 @ 09:14:
Hihi, zoiets kom je in lvl 3 van 'Trytohack' al tegen ofzo.

..of bij een van de vele 'my-first-website' handleidingen op internet: http://www.html-site.nl/wachtwoord1.php

Met uiteraard het legendarische citaat:

Dit script is redelijk veilig. Dat komt omdat de bezoeker niet bij de broncode kan om te zien wat het wachtwoord is.

[rmpel]

Dit is de uiteindelijke oplossing

PHP:

$result = mysql_query("SELECT * FROM log ORDER BY autonr DESC LIMIT 1");
$row = mysql_fetch_assoc($result);

(ook fetch_assoc ipv fetch_array omdat de laatste dubbele records in het geheugen zet; èn associatief èn genummerd, en enkel associatief is nodig)

PHP:

$row = mysql_query("SELECT * FROM log ORDER BY autonr DESC LIMIT 0,1");

Neem ik aan?

mysql_query geeft geen row maar een resource_id terug, wellicht zou dit wel moeten kunnen;

PHP:

$row = mysql_fetch_assoc(mysql_query("SELECT * FROM log ORDER BY autonr DESC LIMIT 0,1"));

maar dat maakt niets uit

[ Voor 0% gewijzigd door rmpel op 06-08-2010 11:28 . Reden: typo ]

[.oisyn]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 11:20:
[...]

..of bij een van de vele 'my-first-website' handleidingen op internet: http://www.html-site.nl/wachtwoord1.php

Met uiteraard het legendarische citaat:

[...]

Oh maar dat is simpel, gewoon een right-click handler maken zodat je niet rightclick -> view source kunt doen

[ Voor 56% gewijzigd door .oisyn op 06-08-2010 11:28 ]

[rmpel]

.oisyn schreef op vrijdag 06 augustus 2010 @ 11:28:
[...]


Oh maar dat is simpel, gewoon een right-click handler maken zodat je niet rightclick -> view source kunt doen

dan gebruiken we CMD+ALT+U

[Verwijderd]

dan druk je toch gewoon op ctr+U in firefox?

of je slaat de pagina gewoon op?

of...

[.oisyn]

Volgens mij ontgaat de sarcasme jullie een beetje...

[Woy]

CyCloneNL schreef op vrijdag 06 augustus 2010 @ 10:06:
en SELECT * meestal langzamer dan individueel de velden aangeven.

Maar dat is eigenlijk een non-argument, want dat zal je echt niet significant gaan merken. Het is niet alsof hij voor elke row op moet gaan zoeken welke velden er zijn.

Het staat gewooon netter, want je kan in een oogopslag zien welke velden er terug gegeven worden, dus je hoeft minder kennis van de DB te hebben om wat met het result te doen, en je kunt eventueel gewoon velden ophalen aan de hand van hun index, zonder dat je in de problemen komt als de volgorde veranderd, of er een ander veld tussen geplaatst word.

[.oisyn]

CyCloneNL schreef op vrijdag 06 augustus 2010 @ 10:06:
en SELECT * meestal langzamer dan individueel de velden aangeven.

Bewijs graag. Of iig waarom jij denkt dat het sneller is.

[Verwijderd]

Ik ben de schrijver van het artikel http://www.html-site.nl/wachtwoord1.php
Ik ben er inmiddels wel achter dat de betreffende beveiliging niet deugd. Dit artikel heb ik al zes jaar geleden geschreven (23 maart 2004), in de dagen dat mijn kennis wat minder groot was. In de tussenliggende tijd heb ik al vele andere artikelen geschreven waarbij het beveiligen met bijvoorbeeld htaccess aan de orde komt.
Ik denk dat het betreffende artikel wel duidelijk aangeeft dat het een systeem is wat de 'gewone gebruiker' zal tegenhouden, meer ook niet.

[orf]

Bewijs graag. Of iig waarom jij denkt dat het sneller is.

Er wordt toch aangegeven dat de mysql server over een traag lijntje benaderd wordt? Als je dan de hoeveelheid data die over dat lijntje gaat kunt verminderen door een beperkt aantal velden te selecten dan kan dat wel degelijk snelheidswinst opleveren.

[ Voor 11% gewijzigd door orf op 06-08-2010 11:46 ]

[TJHeuvel]

.oisyn schreef op vrijdag 06 augustus 2010 @ 11:42:
[...]

Bewijs graag. Of iig waarom jij denkt dat het sneller is.

Ik denk dat het sneller is omdat je dan meer moet nadenken over welke velden je echt gaat gebruiken, in plaats van gewoon maar alles uit de database halen. Door expliciet aan te geven wat je wilt, en ongebruikte velden niet op te vragen kan een performance winst opleveren.

[.oisyn]

orf schreef op vrijdag 06 augustus 2010 @ 11:45:
[...]

Er wordt toch aangegeven dat de mysql server over een traag lijntje benaderd wordt? Als je dan de hoeveelheid data die over dat lijntje gaat kunt verminderen door een beperkt aantal velden te selecten dan kan dat wel degelijk snelheidswinst opleveren.

Ik heb het natuurlijk over het geval dat je sowieso dezelfde velden wilt hebben die * je ook geeft, en volgens mij bedoelt CycloneNL dat ook zo.

CyCloneNL schreef op vrijdag 06 augustus 2010 @ 11:47:
[...]


Ik denk dat het sneller is omdat je dan meer moet nadenken over welke velden je echt gaat gebruiken, in plaats van gewoon maar alles uit de database halen. Door expliciet aan te geven wat je wilt, en ongebruikte velden niet op te vragen kan een performance winst opleveren.

Als je minder opvraagt maakt dat wel uit ja. Ik dacht dat het hier weer ging over het aloude fabeltje dat * langzamer was dan expliciet álle velden opgeven.

[ Voor 91% gewijzigd door .oisyn op 06-08-2010 11:49 ]

[sfranken]

..of bij een van de vele 'my-first-website' handleidingen op internet: http://www.html-site.nl/wachtwoord1.php

Even ter verdediging van HTML-site (waar ik mod ben): Die tutorial is inderdaad slecht, maar het is tegenwoordig een voorbeeld van hoe het dus niet moet.

Goed, ik kwam dit een keer tegen:

PHP:

<?php
ob_start();
if($_SERVER['REMOTE_ADDR'] == '127.0.0.1')
{
    header('Location: /beveiligd.php');
}
else
{
    header('Location: http://www.google.nl');
}
?>

Vond de maker het vreemd dat hij als hij niet via localhost keek elke keer naar google ging (dit snippetje stond tussen 1000+ regels andere slechte code, dus hij had het waarschijnlijk niet gezien)

[.oisyn]

Ook leuk, je kan dus sowieso altijd gewoon zelf /beveiligd.php ophalen

[sfranken]

.oisyn schreef op vrijdag 06 augustus 2010 @ 11:55:
Ook leuk, je kan dus sowieso altijd gewoon zelf /beveiligd.php ophalen

Daar kwam hij zelf ook achter, nadat ongeveer iedereen beveiligd.php had aangehaald zonder de correcte inloggegevens ingevuld te hebben. Door een andere bug ergens maakte het namelijk niet uit wat je invulde, je kwam toch wel op beveiligd.php uit

[.oisyn]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 11:44:
Ik ben de schrijver van het artikel http://www.html-site.nl/wachtwoord1.php
Ik ben er inmiddels wel achter dat de betreffende beveiliging niet deugd. Dit artikel heb ik al zes jaar geleden geschreven (23 maart 2004), in de dagen dat mijn kennis wat minder groot was. In de tussenliggende tijd heb ik al vele andere artikelen geschreven waarbij het beveiligen met bijvoorbeeld htaccess aan de orde komt.
Ik denk dat het betreffende artikel wel duidelijk aangeeft dat het een systeem is wat de 'gewone gebruiker' zal tegenhouden, meer ook niet.

Kun je 'm niet gewoon weghalen dan, of er iig een disclaimer bij zetten dat het absoluut geen beveiliging is? Leuk dat jij 'm jaren geleden hebt geschreven, maar er zullen nog steeds mensen zijn die je oude onjuiste advies opvolgen.

[Verwijderd]

.oisyn schreef op vrijdag 06 augustus 2010 @ 11:55:
Ook leuk, je kan dus sowieso altijd gewoon zelf /beveiligd.php ophalen

Sowieso headers (voor beveiliging) gebruiken is slecht. Je ziet dit ook nog vaak:

code:

if (isset($_POST['ww']) && $_POST['ww'] != "test")
header('Location: fout.php');

edit*: even een verduidelijking.

[ Voor 7% gewijzigd door Verwijderd op 06-08-2010 12:44 ]

[Verwijderd]

.oisyn schreef op vrijdag 06 augustus 2010 @ 12:40:
[...]


of er iig een disclaimer bij zetten dat het absoluut geen beveiliging is?

Zal ik inderdaad eens doen

[Verwijderd]

(ook fetch_assoc ipv fetch_array omdat de laatste dubbele records in het geheugen zet; èn associatief èn genummerd, en enkel associatief is nodig)

Dit kan toch ook gewoon?

code:

mysql_fetch_array($result, MYSQL_ASSOC);

Ik dacht juist altijd dat assoc zwaarder was. Ik weet niet meer waarom

Edit: net even een testcase gedraaid, assoc is sneller...

[ Voor 9% gewijzigd door Verwijderd op 06-08-2010 13:26 ]

[Verwijderd]

Over MySQL en SELECT * versus SELECT velden. Heb ooit meegemaakt dat een SELECT-met-velden query (met minder velden als *) er minuten over deed om uit gevoerd te worden terwijl SELECT * binnen een seconde klaar was. Probleem lag toen ergens bij MySQL. Nooit kunnen vinden war het precies vandaan kwam. Maar: ik gok op gare server, gare settings en een vreemde random-bug-zij-verschijnsel iets. (En ja: velden of * was het enige verschil tussen de queries).

[Avalaxy]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 12:43:
[...]

Sowieso headers (voor beveiliging) gebruiken is slecht. Je ziet dit ook nog vaak:

code:

if (isset($_POST['ww']) && $_POST['ww'] != "test")
header('Location: fout.php');

edit*: even een verduidelijking.

Waarom geen headers?

[RobIII]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 12:44:
[...]


Zal ik inderdaad eens doen

Ik zou het eerder offline halen. Je hebt het over "100% waterdicht is dit systeem niet" maar dit artikel mag wmb niet eens refereren aan de term "beveiliging". Het is niet eens 1% waterdicht. Het is zo lek als maar zijn kan. Het is een compleet waardeloze wassen neus welke, at best, een huis-tuin-en-keuken-gebruiker even buiten houdt.

quote: http://www.html-site.nl/wachtwoord1.php

Dit script is redelijk veilig. Dat komt omdat de bezoeker niet bij de broncode kan om te zien wat het wachtwoord is.

Het komt niet eens in de buurt van veilig Iedereen (en dan bedoel ik iedereen behalve je oma) kan bij de broncode. Je wekt in het artikel dat het "wel aardig goed zit" en "afdoende" zou zijn. Dat is het geenszins. Offline ermee en vlug a.u.b. voordat iemand het in z'n hoofd haalt hier mee aan de slag te gaan

[ Voor 42% gewijzigd door RobIII op 06-08-2010 14:16 ]

[Verwijderd]

Avalaxy schreef op vrijdag 06 augustus 2010 @ 14:05:
[...]


Waarom geen headers?

Omdat headers niet werken bij bijv putty... Deze kan dan gewoon op de pagina komen. Gebruik je daarentegen nog een die onder de header kan het weer wel

[Noxious]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 14:31:
[...]

Omdat headers niet werken bij bijv putty... Deze kan dan gewoon op de pagina komen. Gebruik je daarentegen nog een die onder de header kan het weer wel

En wat is een goed alternatief? Want volgens mij klopt je laatste zin niet helemaal

[AtleX]

Zijn laatste zin klopt wel. Het probleem is dat een UA die header kan negeren en dus alsnog de pagina kan zien. Als je onder header() nog die() zet tackel je dat probleem.

[Noxious]

Ah, ik las 'die' als het Nederlandse woord, vandaar mijn verwarring.

[Avalaxy]

AtleX schreef op vrijdag 06 augustus 2010 @ 14:37:
Zijn laatste zin klopt wel. Het probleem is dat een UA die header kan negeren en dus alsnog de pagina kan zien. Als je onder header() nog die() zet tackel je dat probleem.

Ah ok, dus als ik het goed begrijp kun je dit doen:

Header -> stuurt je naar een 'mooie' pagina met een nette error erop.
Die/exit -> geeft simpelweg een losse error in de vorm van een string wanneer de header niet werkt.

Thanks voor de tip

[Verwijderd]

Nee.

Met header('Location: http://blablabla'); zeg je dat de browser naar een andere pagina moet. Maar in de respons kún je wél een content body meesturen. Als je direct na die header(); call die exit(); aanroept, garandeer je dat er onbedoeld geen informatie naar de bezoeker gestuurd wordt. Want dat gebeurt wel degelijk, alleen zal een browser er zelf niets mee doen. Maar het is wel degelijk via HTTP naar de client gestuurd.

[Jegorex]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 12:43:
[...]

Sowieso headers (voor beveiliging) gebruiken is slecht. Je ziet dit ook nog vaak:

code:

if (isset($_POST['ww']) && $_POST['ww'] != "test")
header('Location: fout.php');

edit*: even een verduidelijking.

code:

if (isset($_POST['ww']) && $_POST['ww'] != "test")

Als $_POST['ww'] niet bestaat zal hier ook nooit true worden gegeven.

[codebeat]

Las net een bericht van iemand die een opmerking plaatste over nederlands opgenomen in sourcode, het zou verboden moeten worden. Vooral designers hebben daar een handje van. Van gemixte functienamen, ziets als:
getBestandsnaam() of zoiets (en echt dit heb ik gezien) daar krijg ik helemaal koude rillingen van.

Mensen die programmeren met nederlandse variabelenamen/functienamen neem ik over het algemeen niet serieus (Dan neem je het vak ook niet serieus). Dat zijn hobbyisten,immers is de taal in het engels dus doe je alles in het engels, logisch is dat.

Ook mensen die nu nog steeds met dreamweaver werken en daar volledig op vertrouwen. Nog erger is frontpage ;-) Weten niet eens wat er precies gebeurd in de code. Of op zijn php3/php4 stijl, lekker alles door elkaar flikkeren, een heerlijke vermicellisoep van php,html,javascript,css en dan vaak ook nog SQL erdoorheen. En dan wanneer je een aktie moet herhalen je dan gewoon even copy en paste doet. Handig! ;-(

Ik doe geen onderhoud meer aan dat soort oude code, ik weiger het. Bij een vorig bedrijf waar ik heb gewerkt hadden we op een gegeven moment een webshop nodig. Ze hadden nog wel een eigengemaakte 'liggen', moest ik maar even naar kijken. Wat tref je aan: een heerlijke vermicellisoep, gewoonweg niet mogelijk om te hergebruiken. Zag er aan de buitenkant wel leuk uit, maar de binnenkant......

De opleidingen zijn daar ook de schuld van, technieken zijn vaak verouderd omdat de docent niet meegaat. het is vaak onder de maat. Er wordt ook veel te weinig aandacht besteed aan hergebruik (bijvoorbeeld werken met templates) en het schrijven van overzichtelijke en nette code (structuur). Vaak niet gespitst op de praktijk. Voorbeelden zijn ook vaak in het Nederlands, dat is een slecht begin. Dan leer je ook niet denken in het Engels en krijg je problemen wanneer je iets download dat wel in het Engels is.

Ik heb het zelf ook gezien bij Vijfhart, een cursus Java. Gewoon triest wat je daar krijgt (en zeker als je kijkt wat het kost). Krijg je die onzin om priemgetallen af te drukken, ik wil weten hoe ik een button maak etc. Werken met de Swing bibliotheek.Ook wel lache, vraag je aan de docent iets over arrays, moet ie gaan navragen bij zijn collega haha. pfff. In de helft van de tijd was ik al klaar, stelt niets voor, zonde van je geld.

Mijn broer heeft in 2009 een cursus gevolgd bij EduVision, om bijvoorbeeld webshops te bouwen. Ik heb het cursusmateriaal gezien. Is voor een leek te hoog gegrepen en voor een gevorderde te eenvoudig en..... weer oude sh*t. Ze maken dat cursusmateriaal 1 keer en dan wordt het niet meer geupdate voor een zeer lange tijd. Je betaald dus een hoop geld voor een cursus dat onder de maat is.

Ik heb zelf ook meegemaakt met een stagiaire (weet niet meer van welke instelling helaas), laat ik daar maar over ophouden, niveau if..then..else.

Was een nieuwe jongen komen werken bij een oud werkgever van mij. Hij ging bezig met een project, ik moest toen ook iets daaraan doen en kwam een stuk code tegen.......
Hij moest een array uitlezen en dat had ie eigenlijk met een loop kunnen doen. Er zaten iets van 150 elementen in en dit had ie voluit geschreven, dus 150 keer stond er hetzelfde iin (alleen elementnummer werd steeds met 1 opgehoogd). En, die jongen kwam van de TU...........sad.....

[Avalaxy]

@ boven:

Docenten zijn vaak zelf ook geen programmeurs maar hebben ooit eens ergens de basis gehoord en moeten dat door vertellen. Mijn programmeerdocent aan de Hogeschool Rotterdam wist niet eens hoe een try/catch systeem werkte en moest dat aan ons (eerstejaarsstudenten informatica) vragen

Ik blijf er dan ook bij dat je programmeren beter uit een goed boek kunt leren dan via school of via internet... In beide gevallen zijn het vaak ook maar mensen die denken dat ze het snappen en zomaar iets in elkaar flansen wat nergens op lijkt. Als je een goed boek hebt die goede reviews heeft dan zit je meestal wel goed (denk aan een PHP boek van Rasmus Lerdorf).

[Verwijderd]

Erwines schreef op zaterdag 07 augustus 2010 @ 16:00:
Las net een bericht van iemand die een opmerking plaatste over nederlands opgenomen in sourcode, het zou verboden moeten worden. Vooral designers hebben daar een handje van. Van gemixte functienamen, ziets als:
getBestandsnaam() of zoiets (en echt dit heb ik gezien) daar krijg ik helemaal koude rillingen van.

Mensen die programmeren met nederlandse variabelenamen/functienamen neem ik over het algemeen niet serieus (Dan neem je het vak ook niet serieus). Dat zijn hobbyisten,immers is de taal in het engels dus doe je alles in het engels, logisch is dat.

STOP. De taal syntax is in C#, VB, C++, Java, etc. Het heeft niks met een gesproken taal te maken. Echter heb je wel gelijk dat een functienaam: getBestandsnaam fout is. Doe dan alles in het Nederlands of niets.

Dus:
krijgBestandsnaam();
of
getFileName();

[kenneth]

Erwines schreef op zaterdag 07 augustus 2010 @ 16:00:
Las net een bericht van iemand die een opmerking plaatste over nederlands opgenomen in sourcode, het zou verboden moeten worden. Vooral designers hebben daar een handje van. Van gemixte functienamen, ziets als:
getBestandsnaam() of zoiets (en echt dit heb ik gezien) daar krijg ik helemaal koude rillingen van.

Mensen die programmeren met nederlandse variabelenamen/functienamen neem ik over het algemeen niet serieus (Dan neem je het vak ook niet serieus). Dat zijn hobbyisten,immers is de taal in het engels dus doe je alles in het engels, logisch is dat.

Als je mensen niet serieus neemt omdat ze een andere conventie hebben mbt taalkeuze dan neem je je vak niet serieus.

[Haan]

Toch doe ik het soms wel gemixt, omdat niet alles even makkelijk te vertalen is. Zo heb je bijvoorbeeld bij ROC's te maken met stages met bijhorende termen als praktijkopleider, praktijkbegeleider, stageplaats, kerntaken etc. en als je dat allemaal naar engels wil vertalen, moet je of een vertaalbureau inschakelen, of uren lopen puzzelen Dus dan maar wel GetPraktijkOpleider doen, ook al is het wel lelijk.

[RayNbow]

Erwines schreef op zaterdag 07 augustus 2010 @ 16:00:
Las net een bericht van iemand die een opmerking plaatste over nederlands opgenomen in sourcode, het zou verboden moeten worden.

Eerder in deze discussiedraad wordt echter een sterk argument voor het gebruik van Nederlands genoemd. Sommige woorden zijn niet goed te vertalen.

Janoz schreef op donderdag 27 mei 2010 @ 18:33:
[...]
Ik pleit in de projecten waarin ik zit er altijd voor om bij het domein altijd de terminologie over te nemen die de klant zelf ook gebruikt. Is alles in het nederlands, dan is het domein dus ook in het nederlands.
[...]

(Link naar gehele reactie)

[ Voor 18% gewijzigd door RayNbow op 07-08-2010 16:23 ]

[Crazy D]

Erwines schreef op zaterdag 07 augustus 2010 @ 16:00:
Las net een bericht van iemand die een opmerking plaatste over nederlands opgenomen in sourcode, het zou verboden moeten worden. Vooral designers hebben daar een handje van. Van gemixte functienamen, ziets als:
getBestandsnaam() of zoiets (en echt dit heb ik gezien) daar krijg ik helemaal koude rillingen van.

Wat een onzin. Er is voor mij maar 1 regel: namen moeten helder zijn. En als dat als native dutch speaker een nederlandse functienaam is, heb ik daar totaal geen moeite mee. Dat ie met get begint, vind ik ook niet eens zo gek, zo groepeer je 'm in de intellisence in ieder geval samen met andere get-functies (al dan niet met nederlandse of engelse namen). (in een internationaal bedrijf met ontwikkelaars in verschillende landen is dit uiteraard een ander verhaal, je moet in dat geval elkaars code gewoon kunnen lezen en voor een neem-een-willekeurig-buitenland zal Nederlands idd wat lastiger te begrijpen zijn)

[Verwijderd]

RayNbow schreef op zaterdag 07 augustus 2010 @ 16:22:
(Link naar gehele reactie)

offtopic:
Quotes hebben hier automatisch een link naar de gehele reactie

[RayNbow]

Verwijderd schreef op zaterdag 07 augustus 2010 @ 16:25:
[...]

offtopic:
Quotes hebben hier automatisch een link naar de gehele reactie

Dat weet ik, maar de user waar ik op reageer is redelijk nieuw.

[Janoz]

@Erwines: Begin hier ( Janoz in "[alg] Slechtste programmeervoorbeelden d..." ) maar met lezen om te zien waarom ik jouw rant niet serieus neem.. Voor jou dan ook deze uitdaging : Janoz in "[alg] Slechtste programmeervoorbeelden d..."

@ Sanderev66: Nou, dat lijkt me juist een heel stuk erger. Dingen als get en set zijn eigenlijk zo ongeveer standaard in de taal. Die vervangen door hun equivalenten zie je eigenlijk alleen bij speciale talen waarbij programmeren aan kinderen geleerd wordt. Het punt voor het gebruik van niet engels is niet de get en de set, maar juist hetgeen je get en set. Dat moet duidelijk zijn.

--edit-- Ah, velen zijn mij al voor

[Alex)]

Ik probeer mijn code zoveel mogelijk Engelstalig te houden, wat dus ook inhoudt dat method names, parameters, comments en check-in notes Engelstalig zijn. Het domain houd ik meestal dan weer wel Nederlandstalig, vaak omdat het klantspecifiek is en omdat het door anderen ook nog te begrijpen moet zijn.

[Janoz]

Precies. Ik hekel af en toe ook mijn eigen project nu waarbij ik telkens maar moet hopen dat ergens in het FO of TO opgenomen is welke vertaling er nu eigenlijk bij welke property hoort. Dat wordt heel vermoeiend wanneer heel het WOZ domein (incl specificatie documenten) in het Nederlands is, de klant het over de nederlandse namen heeft en er vervolgens iemand is geweest die willekeurig enkele ingelse namen erbij bedacht heeft vanwege 1 of andere code conventie.. Nee, base year gebruiken ipv peiljaar. Dat maakt het een stuk duidelijker (base year heb ik trouwens zelf moeten bedenken , maar overal in de code waar ik het over base year heb neem ik tussen haakjes peiljaar op)

[ZpAz]

Verwijderd schreef op zaterdag 07 augustus 2010 @ 16:16:
[...]

STOP. De taal syntax is in C#, VB, C++, Java, etc. Het heeft niks met een gesproken taal te maken. Echter heb je wel gelijk dat een functienaam: getBestandsnaam fout is. Doe dan alles in het Nederlands of niets.

Dus:
krijgBestandsnaam();
of
getFileName();

En dan pak je standaard functies uit de betreffende taal en dan krijg je iets als.

PHP:

public function verwijderVolledigeMap($pad) { //public function is engels, moet het nu publieke functie zijn?
   $bestanden = scan_dir($pad); //scan_dir, standaard php functie, dat is toch ook geen lees_map_door
   foreach($bestanden as $bestand) { //foreach, voorelke? as als?
     if(is_file($pad . '/' . $bestand)) { //is_file is_bestand 
        unlink($bestand); //Geen idee wat hier een propere nederlandse vertaling voor zou zijn
     }
   }
}

Nederlandse code is blegh, de hele wereld doet het in het engels, wil je een library van een ander gebruiken is het vaak Engels (ik ken werkelijk geen NL code lib) en als iemand dat van jou wil gebruiken limiteer je het dan ook tot de Nederlands sprekende personen.

@Reacties hierboven, okee misschien heb je dus 'enkele uitzonderingen' maar dingen als 'verwijderVolledigeMap()' oid hoeven van mij echt niet in het Nederlands.

[ Voor 7% gewijzigd door ZpAz op 07-08-2010 19:02 ]

[Matis]

Ik heb liever correct Nederlands (zeker als commentaar) dan gebrekkig, of zelfs fout Engels.

Zie ook Matis in "[alg] Slechtste programmeervoorbeelden d..."

[ZpAz]

Matis schreef op zaterdag 07 augustus 2010 @ 19:16:
Ik heb liever correct Nederlands (zeker als commentaar) dan gebrekkig, of zelfs fout Engels.

Zie ook Matis in "[alg] Slechtste programmeervoorbeelden d..."

Geweldig

Tsja, okee steenkolenengels is ook niet alles.

[Alfredo]

Als je Flash Pro in het Nederlands installeert, krijg je ook foutmeldingen in het Nederlands. Dat geeft pareltjes zoals:

Naamruimteattributen zijn niet toegestaan bij interfacemethoden.
Een 'super'-instructie kan alleen als het laatste item in een constructorinitialisatielijst worden gebruikt.
Tenminste één vertakkingsdoel is geen geldige instructie in de methode.

Ik vraag mensen die met zoiets afkomen dan ook gewoon het foutnummer, zodat de Engelse variant kan opzoeken.

[ Voor 8% gewijzigd door Alfredo op 07-08-2010 19:52 ]

[Haan]

Hetzelfde heb je als je in.NET ontwikkelt op een NL besturingssysteem ja, vreselijk irritant.

[Alex)]

SharePoint-ontwikkeling is ook een ramp in het Nederlands

Sowieso is SharePoint-ontwikkeling een vak apart

[Onbekend]

Matis schreef op zaterdag 07 augustus 2010 @ 19:16:
Ik heb liever correct Nederlands (zeker als commentaar) dan gebrekkig, of zelfs fout Engels.

Zie ook Matis in "[alg] Slechtste programmeervoorbeelden d..."

"Standaard anders"

Als ik zelf commentaar schrijf, doe ik dat in het Nederlands. Ik begrijp bij het teruglezen meteen wat er bedoelt wordt.
Stukken code die ik van het internet heb geplukt en ongewijzigd zijn blijft het originele commentaar ook staan. Dit is meestal in het Engels. Hiermee kan ik meteen zien of ik ooit die code heb geschreven, of dat dat stuk code van het internet af komt en er nog mogelijk fouten in zitten.

[PiepPiep]

Haan schreef op zaterdag 07 augustus 2010 @ 20:53:
Hetzelfde heb je als je in.NET ontwikkelt op een NL besturingssysteem ja, vreselijk irritant.

Ik keek erg verbaast toen ik eens de melding "een niet ondervangen uitzondering opgetreden" zag.
Unhandled exception occured is dan toch duidelijker.

Je kan trouwens zonder steenkolen engels of nederlands ook erg onduidelijke dingen creeren met onduidelijke variable namen.
Volgens mij was de naam nietmeenemen, kan ook iets anders geweest zijn maar het begon iig met niet. Daardoor kreeg je

code:

if not nietmenemen then

Ik heb snel overal de true en false omgewisselt bij dat ding en hem meenemen genoemd.

[Verwijderd]

ZpAz schreef op zaterdag 07 augustus 2010 @ 18:48:
[...]


En dan pak je standaard functies uit de betreffende taal en dan krijg je iets als.

PHP:

public function verwijderVolledigeMap($pad) { //public function is engels, moet het nu publieke functie zijn?
   $bestanden = scan_dir($pad); //scan_dir, standaard php functie, dat is toch ook geen lees_map_door
   foreach($bestanden as $bestand) { //foreach, voorelke? as als?
     if(is_file($pad . '/' . $bestand)) { //is_file is_bestand 
        unlink($bestand); //Geen idee wat hier een propere nederlandse vertaling voor zou zijn
     }
   }
}

Nederlandse code is blegh, de hele wereld doet het in het engels, wil je een library van een ander gebruiken is het vaak Engels (ik ken werkelijk geen NL code lib) en als iemand dat van jou wil gebruiken limiteer je het dan ook tot de Nederlands sprekende personen.

@Reacties hierboven, okee misschien heb je dus 'enkele uitzonderingen' maar dingen als 'verwijderVolledigeMap()' oid hoeven van mij echt niet in het Nederlands.

Leuke voorbeelden. Unlink zal je naar ontbind(..) kunnen vertalen Ik was zelf eens bezig met een op VB gebaseerde taal met Nederlands-ogende syntax.

[Bv202]

Nederlands-ogende syntax? Alleen het idee al

Ik schrijf alles gewoon in het Engels

En wat Erwines over opleidingen vertelt, kan ik enkel bevestigen. Twee jaar geleden moesten we Frontpage gebruiken om websites te maken. En liefst nog frames gebruiken ook, want die zijn toch zo handig

[codebeat]

Haha, grappig dat het wel het een en ander teweeg brengt, is goed. Maarre wat Kenneth zegt ga ik niet eens op in.

Als bibliothekenen met classes bijvoorbeeld allemaal een publieke functie die getFileName() heet en jij gaat ineens een eigen klasse maken met getBestandnaam(), de logica en consistentie is dan gebroken. Je kunt dan niet meer 'gissen' naar een logische naam (of verwachten dat de functienaam zo heet). Aangezien de meeste bibliotheek in het Engels zijn is het gewoon niet handig ineens een andere taal te gaan gebruiken. Dan wordt het een soort 'toren van Babel'. Het kan ook veel meer tijd kosten omdat je niet kunt aannemen dat zoiets als getFileName() bestaat, Dat kan je onzeker maken (je moet alles extra controleren) en kan tot extra fouten leiden. Natuurlijk heeft dit alles met afspraken te maken maar moet ongeschreven regel zijn. Als iedereen dezelfde taal spreekt wordt het een eenduidig geheel en kun je oplossingen goed hergebruiken. Stel dat je een goede oplossing hebt gemaakt en je wilt dat gaan hergebruiken in een internationale site dan zit je al. Stel dan je het moet maken voor bedrijf waar geen Nederlands wordt gesproken. Is niet te onderhouden door iemand die geen Nederlands spreekt. Stel je voor dat je code tegenkomt in het chinees maar jij moet een aanpassing doen, word je ook geen wijs uit als je geen chinees spreekt. Als je alles in het Nederlands of andere taal dan behalve Engels doet, bind je de gemaakte oplossing aan de taal en dus niet universeel te gebruiken. Het is ook wel leuk wat Alex) schrijft: "omdat het door anderen ook nog te begrijpen moet zijn.", inderdaad, maar niet in het Nederlands.

Bijvoorbeeld SQL veldnamen in het Nederlands, de tabelnaam moet zeggen waarvoor het bedoeld is, niet specifiek de veldnaam. Dat is onjuist gebruik van een veldnaam. Bijvoorbeeld als je de tabel ORDERS hebt dan hoeft het niet specifiek ordernumber of bestellingsnr of bestellingsnummer of whatever te bevatten, nr zou al genoeg zijn omdat een order een nummer heeft. In de description kan je dat eventueel toelichten als je dat echt wilt. Dus het is niet nodig alles letterlijk te vertalen (zoals iemand eerder zei, je weet immers uit welke tabe je het haalt).

Wat je ook HEEL vaak ziet is dat binnen een functie een foutmelding wordt gegenereerd. Dat is ook fout, op top-level (bij aanroep van een functie) mag dat wel maar in een biblotheek bijvoorbeeld niet. Daar zijn vier problemen mee:
a) de taal van de foutmelding
b) Niet mogelijk een alternatief bericht te tonen
c) Zelf de afhandeling te doen (bijvoorbeeld iets wegschrijven voor de foutmelding)
d) Als je de foutafhandeling anders wilt moet je de bibliotheek aanpassen (iets wat je niet wilt, want dn krijg je in de loop der tijd verschillende versies van de biblitoheek, dat is niet de bedoeling van een bibliotheek)

Een goed voorbeeld (van hoe het wel moet) is bijvoorbeeld de Windows API. Daar komt geen enkele foutmelding in voor, wel foutcodes of true or false. (met uitzondering van exeptions maar die kun je ook weer afvangen maar daar gaat het even niet om).

Bijvoorbeeld in PHP zie je dit soort dingen regelmatig terugkomen, bijvoorbeeld:
function getFileContent( $sFileName )
{
if( !file_exists( $sFileName ))
{ die( 'File does not exists.' ); }
{...}
}

Even niet mierenneu*en over de functie en wat voor checks je op voorhand zou kunnen doen, daar gaat het nu even niet om, het is een voorbeeld.

de functie zou dit moeten doen:
function getFileContent( $sFileName )
{
if( !file_exists( $sFileName ))
{ return false; }
{...}
}

Nu kan ik zelf gaan bepalen wat ik met het resultaat ga doen. Sla ik een andere route in, toon ik een bericht (kan ook in de gewenste taal) etc.Het programma breekt niet af totdat ik het zelf afbreek.

Het is vaak een probleem dat oplossingen voor slechts 1 toepassing worden gemaakt (of 1 taal) of zo worden gemaakt dat je vast zit in een bepaalde programma route. Dat is ruk en niet efficient. Niet denken in kort termijn maar nadenken of je het nog zou kunnen gebruiken in een andere situatie. Als je op voorhand nadenkt over andere toepassingen van je oplossing kan dat ontzettend veel (ontwikkel) tijd schelen in de toekomst. Want "let's face it", heel veel oplossingen komen op hetzelfde neer en het is zonde als je iedere keer het wiel opnieuw moet uitvinden, alleen vanwege een andere taal, tabelnaam etc.

[BarôZZa]

Een 'return false' vind ik in de veel gevallen nog veel erger dan een die(). Een return false is leuk als je één check hebt, maar als je er meerdere hebt, dan is het een drama. Niks is erger dan een grote functie die simpelweg 'false' returnt.
Bij de die() zie je tenminste nog waar het de soep in loopt. Uiteraard wil je dat niet gebruiken bij zaken die nog wel eens redelijkerwijs willen voorkomen.

Je zal liever gewoon exceptions willen gooien.

Niet dat ik overigens nooit gebruik maak van return false of een die(). De die() is prima te gebruiken voor zaken die praktisch nooit voorkomen, maar waarbij je niet wilt dat het script doorloopt. Ik heb hem bijvoorbeeld standaard achter de mysql_select_db() staan. Shoot me.

Ik ben trouwens ook allergisch voor code van overijverige mensen die teveel onnodige checks gebruiken. Soms gewoon meerdere keren achter elkaar dezelfde zooi checken. Wat is dat vermoeiend om door te komen.

Waar blijven trouwens de echt grappige onlogische en overbodige stukjes code ipv dat gemiep over comments, namen van variabelen etc

RobIII schreef op vrijdag 06 augustus 2010 @ 14:09:
[...]

Ik zou het eerder offline halen. Je hebt het over "100% waterdicht is dit systeem niet" maar dit artikel mag wmb niet eens refereren aan de term "beveiliging". Het is niet eens 1% waterdicht. Het is zo lek als maar zijn kan. Het is een compleet waardeloze wassen neus welke, at best, een huis-tuin-en-keuken-gebruiker even buiten houdt.

[...]

Het komt niet eens in de buurt van veilig Iedereen (en dan bedoel ik iedereen behalve je oma) kan bij de broncode. Je wekt in het artikel dat het "wel aardig goed zit" en "afdoende" zou zijn. Dat is het geenszins. Offline ermee en vlug a.u.b. voordat iemand het in z'n hoofd haalt hier mee aan de slag te gaan

Ik weet nog dat je vroeger in het gratis Tripod hosting tijdperk de volgende beveiliging vaak tegenkwam:

JavaScript:

var password=window.prompt("Password:","");
document.location='http://members.tripod.com/~mooiesite/'+password+'.html';

[Janoz]

@Erwines: Heb je nu al de posts gelezen waar ik en anderen naar hebben gelinkt? Als je zo overtuigd bent van het amateurisme van mensen die niet engelse tekst uit het probleemdomein overnemen in hun code dan moet het voor jou geen enkele moeite kosten om hier wat van te maken: Janoz in "[alg] Slechtste programmeervoorbeelden d..."

En nee, dat gaat niet om getBestandsnaam ipv getFilename in een herbruikbare library.

Wat nu wanneer je een (nederlandse) opdrachtgever hebt die een feestjes registratie bij wil houden waarbij 1 van de properties een gezelligheidsindex is? Ga je daar dan cosyIndex van maken?

Emn als die code vervolgens in India onderhouden wordt dan maakt het voor die indier eigenlijk ook geen reet meer uit of het nu een property 'cosy' of 'gezeligheid' is. Van beiden begrijpt hij geen reet. Het enige verschil is dat in de communicatie met de klant 'gezelligheid' altijd voorkomt terwijl de indier het pas zal begrijpen wanneer je 'journeyman' in je code had staan.

[Caelorum]

Wat nu wanneer je een (nederlandse) opdrachtgever hebt die een feestjes registratie bij wil houden waarbij 1 van de properties een gezelligheidsindex is? Ga je daar dan cosyIndex van maken?

Emn als die code vervolgens in India onderhouden wordt dan maakt het voor die indier eigenlijk ook geen reet meer uit of het nu een property 'cosy' of 'gezeligheid' is. Van beiden begrijpt hij geen reet. Het enige verschil is dat in de communicatie met de klant 'gezelligheid' altijd voorkomt terwijl de indier het pas zal begrijpen wanneer je 'journeyman' in je code had staan.

ehh.. cosinessIndex of sociabilityIndex.
enneh gezelligheid != journeyman. Ik denk dat als je jouneyman gaat gebruiken die Indier helemaal niet meer weet waar het over gaat
Daarnaast is in Indie Engels 1 van de officiele talen..

[ Voor 4% gewijzigd door Caelorum op 08-08-2010 10:06 ]

[Janoz]

http://translate.google.com/#nl|en|gezeligheid

[ Voor 10% gewijzigd door Janoz op 08-08-2010 10:05 ]

[codebeat]

Beste BarôZZa, wat je hierboven schrijft kan ik opmerken dat je niet helemaal begrijpt wat het nut is van een return waarde en ook niet helemaal begrijpt wat ik met mijn uitleg bedoelde. Je schrijft: "Een 'return false' vind ik in de veel gevallen nog veel erger dan een die()." Bij een die() breekt je programma af, stopt je programma onheroepelijk en bij een return false niet.

Je schreef ooK: "De die() is prima te gebruiken voor zaken die praktisch nooit voorkomen, maar waarbij je niet wilt dat het script doorloopt." Begrijp de redenering wel maar In het geval van het voorbeeld is dit zeer onwenselijk. Als het gaat om een plugin (bijvoorbeeld de gd lib) kan ik mij wel voorstellen dat je een die() gebruikt wanneer deze niet beschikbaar is omdat deze vereist is voor de functionaliteite die je bouwt.Wanneer je aan het bouwen bent kom je daar snel genoeg achter en dat is het ook het enige moment waarbij deze foutmelding mag voorkomen.

In sommige gevallen hoeft je niet precies te weten wat er is misgegaan omdat de functienaam dat al aangeeft en in sommige gevallen wil je dat wel weten maar return je bijvoorbeeld een foutcode. Weet je precies wat er aan de hand is. Dat kun je bijvoorbeeld doen me vooraf gedefinieerde defines. Daar heb je checks voor nodig waar jij zo'n hekel aan hebt. Het is altijd beter om zelf de fout af te vangen dan dat de interpreter met een fout komt (staat ook veel beter naar de klant of de gebruiker dan alleen maar een wit scherm en een foutmelding). Als de interpreter met een fout komt kan dat betekenen dat onvoldoende aandacht hebt besteed aan het ontwerp en niet nagedacht hebt over de mogelijke fouten. Daarnaast kun je er niets meer aan veranderen wanneer de interpreter met een fout komt. Ziet er heel slordig uit.

Bij een taal als PHP MOET je juist controleren op geldigheid en/of type omdat variabelen geen type hebben, het kan dus (per ongeluk) van alles zijn. Dat het overbodig is of niet hangt helemaal samen met je ontwerp. Teveel checks kunnen in sommige situaties voorkomen en in sommige situaties is het genoeg, dat ligt bevoorbeeld weer aan welke functies je gebruikt of dat je een ekele functie gebruikt. Iets teveel checken is nooit erg, het maakt het alleen maar robuust en is dus berekend op meerdere situaties. Dat geeft aan dat je er over nagedacht hebt en dat de oplossing breder inzetbaar is dan alleen het project waar je op dat moment aan werkt. Dat is vaak het probleem, er wordt vaak maar in 1 richting gedacht, alleen het project. Daardoor krijg je ook opmerkingen zoals van BarôZZa.

Weinig checks of geen checks is een teken van luiheid of onwetendheid. Checks kunnen juist helpen om duidelijkheid te scheppen in wat verwacht wordt zonder dat daar comments voor nodig zijn.

[Caelorum]

Janoz schreef op zondag 08 augustus 2010 @ 10:05:
http://translate.google.com/#nl|en|gezeligheid

http://translate.google.com/#nl|en|gezelligheid
Verschilt maar 1 "l' ^^
http://translate.google.com/#en|nl|journeyman

[ Voor 16% gewijzigd door Caelorum op 08-08-2010 10:10 ]

[codebeat]

Janoz, lees nog eens wat ik precies heb geschreven. Naam van de tabel kan al heel veel doen, dan maakt het niet uit of het cosyindex is, je kunt er dan gewoon index van maken. Daarnaast kun je de moeite nemem een omschrijving bij het veld te plaatsen (iets wat veel te weinig gebeurd). Iemand in India snapt dat heus wel. Omdat de naam van de tabel al verteld waar het over gaat. Zoiets heet een functioneel ontwerp, daar begint het mee.

[ Voor 96% gewijzigd door codebeat op 08-08-2010 10:20 ]

[kenneth]

Erwines schreef op zondag 08 augustus 2010 @ 02:15:
Haha, grappig dat het wel het een en ander teweeg brengt, is goed. Maarre wat Kenneth zegt ga ik niet eens op in.

Het is vooral grappig dat je het topic komt binnenwandelen en zaken als absolute waarheid neerzet terwijl door discussie in ditzelfde topic heeft aangetoond dat er nog heel wat nuances aan zaken kan zitten.

Maar waarom ga je niet in op wat ik zeg? Je komt de absolute waarheid brengen, ik geef daar een m.i. nuttige draai aan maar dan ga je er niet op in?

[codebeat]

kenneth, ik geef aan waarom ik dat vind hoe dat komt dat ik dat vind. jij draait alleen mijn woorden/uitdrukking/zin alleen maar om. Kan je niks mee en is dus totaal overbodig, dan kan je net zo goed niets zeggen.

Je zegt in je tweede bericht dat ik de absolute waarheid loop te verkondigen, helemaal niet zo, je mag het er niet mee eens zijn hoor. Het zijn de dingen die ik zie en die ik wil ik graag delen. Ik ben denk wat ouder dan de meeste hier en opleidingen zijn soms echt onder de maat, vind ik gewoon jammer. Ik wil het helemaal niet hebben over hoeveelheid ervaring of wat dan ook, Ik weet ook niet alles (gelukkig maar) maar wat ik weet weet ik best aardig en sta ook open voor andere gedachten. Een bescheiden houding dus. Wel kan ik zeggen uit ervaring wat mijn bevindingen zijn en wat ik hier vertel, werkt. Ik heb er elke dag plezier van.

[ Voor 60% gewijzigd door codebeat op 08-08-2010 10:41 ]

[Matis]

Erwines schreef op zondag 08 augustus 2010 @ 10:28:
kenneth, ik geef aan waarom ik dat vind hoe dat komt dat ik dat vind. jij draait alleen mijn woorden/uitdrukking/zin alleen maar om. Kan je niks mee en is dus totaal overbodig, dan kan je net zo goed niets zeggen.

Jij brengt jouw filosofie als de enige waarheid. Als daar vervolgens terechte vraagtekens bij worden gezet, dan zeg jij dat niemand het begrijpt en dat je er niet op in wilt gaan.

[Janoz]

Erwines. Ik lees wat je schrijft, maar lees ook eens wat ik eerder beschreven heb.

Als je daadwerkelijk bezig bent met proffesionele software ontwikkeling dan is de kans heel groot dat je geen software aan het schrijven bent die je eigen probleem oplost. Sterker nog, de kans is groot dat je klant meer verstand heeft van het probleem dan jijzelf. De enige meerwaarde die jij hebt is dat je toevallig erg bedreven bent in het omzetten van het probleem dat in het hoofd van de klant zit naar een stuk software dat dit probleem oplost.

Het getuigt dan van een misplaatste vorm van arrogantie om te denken dat je de hele terminologie van het probleem dan gelijk ook maar even aan gaat passen. "Ja, ik weet dat jullie het al 20 jaar over een 'draagkrachtmeting' hebben en dat dat woordt voor al jullie 2000 medewerkers precies een beeld oproept van wat het is, maar ik ben een programeur en we doen alles in het engels dus pas jullie terminologie maar even aan. En mochten jullie nog een RFC hebben dan heb ik hier eventueel nog wel een transformatie tabelletje waarin jullie de universeel correct door mij zojuist bedachte term kunnen zoeken bij jullie infantiele al 20 jaar in gebruik zijnde termpje in een marge taal anders dan engels"

En de spreekwoordelijke indier maakt het geen reet uit of het een draagkrachtmeting, capacity measurement of flupke heet zolang er in het (voor de rest ook gewoon engelse) FO maar consistent gebruik gemaakt wordt en dat er uit de context duidelijk opgemaakt kan worden dat het om een zelfstandig naamwoord gaat.


Oh, en ik gebruik 'gezelligheid' omdat dit woord eigenlijk alleen in het nederlands voorkomt. (Als je tegen een amerikaan zegt dat je zijn verjaardagsfeest erg cosy vond dan denk ik niet dat hij dat als een compliment opvat)

[ Voor 17% gewijzigd door Janoz op 08-08-2010 10:41 ]

[codebeat]

Janoz, je snapt niet wat ik bedoel te zeggen. Jammer. Je plaatst het helemaal buiten de context.

[ Voor 30% gewijzigd door codebeat op 08-08-2010 10:54 ]

[BarôZZa]

Het punt wat betreft cosy is dat het niet hetzelfde betekent als gezellig. Een gezellig feest hoeft een Engelsman absoluut niet als cosy te beschouwen. Cosy betekent meer knus.

Erwines schreef op zondag 08 augustus 2010 @ 10:05:
Beste BarôZZa, wat je hierboven schrijft kan ik opmerken dat je niet helemaal begrijpt wat het nut is van een return waarde en ook niet helemaal begrijpt wat ik met mijn uitleg bedoelde. Je schrijft: "Een 'return false' vind ik in de veel gevallen nog veel erger dan een die()." Bij een die() breekt je programma af, stopt je programma onheroepelijk en bij een return false niet.

Je schreef ooK: "De die() is prima te gebruiken voor zaken die praktisch nooit voorkomen, maar waarbij je niet wilt dat het script doorloopt." Begrijp de redenering wel maar In het geval van het voorbeeld is dit zeer onwenselijk. Als het gaat om een plugin (bijvoorbeeld de gd lib) kan ik mij wel voorstellen dat je een die() gebruikt wanneer deze niet beschikbaar is omdat deze vereist is voor de functionaliteite die je bouwt.Wanneer je aan het bouwen bent kom je daar snel genoeg achter en dat is het ook het enige moment waarbij deze foutmelding mag voorkomen.

In sommige gevallen hoeft je niet precies te weten wat er is misgegaan omdat de functienaam dat al aangeeft en in sommige gevallen wil je dat wel weten maar return je bijvoorbeeld een foutcode. Weet je precies wat er aan de hand is. Dat kun je bijvoorbeeld doen me vooraf gedefinieerde defines. Daar heb je checks voor nodig waar jij zo'n hekel aan hebt. Het is altijd beter om zelf de fout af te vangen dan dat de interpreter met een fout komt (staat ook veel beter naar de klant of de gebruiker dan alleen maar een wit scherm en een foutmelding). Als de interpreter met een fout komt kan dat betekenen dat onvoldoende aandacht hebt besteed aan het ontwerp en niet nagedacht hebt over de mogelijke fouten. Daarnaast kun je er niets meer aan veranderen wanneer de interpreter met een fout komt. Ziet er heel slordig uit.

Bij een taal als PHP MOET je juist controleren op geldigheid en/of type omdat variabelen geen type hebben, het kan dus (per ongeluk) van alles zijn. Dat het overbodig is of niet hangt helemaal samen met je ontwerp. Teveel checks kunnen in sommige situaties voorkomen en in sommige situaties is het genoeg, dat ligt bevoorbeeld weer aan welke functies je gebruikt of dat je een ekele functie gebruikt. Iets teveel checken is nooit erg, het maakt het alleen maar robuust en is dus berekend op meerdere situaties. Dat geeft aan dat je er over nagedacht hebt en dat de oplossing breder inzetbaar is dan alleen het project waar je op dat moment aan werkt. Dat is vaak het probleem, er wordt vaak maar in 1 richting gedacht, alleen het project. Daardoor krijg je ook opmerkingen zoals van BarôZZa.

Weinig checks of geen checks is een teken van luiheid of onwetendheid. Checks kunnen juist helpen om duidelijkheid te scheppen in wat verwacht wordt zonder dat daar comments voor nodig zijn.

Wat mij betreft mag je je arrogantie een beetje in toom houden.

In jouw voorbeeld is een return false simpelweg nog veel erger dan een die. Stel voor dat je nog een check hebt op de header, de grootte van het bestand etc. Leuk dat je programma dan doorloopt, maar je krijgt geen moer terug.
Als je zo alwetend bent, nooit in één richting denkt en het allemaal zo robuust bouwt, dan weet je dat je dan gewoon een exception gooit die je afvangt met een try/catch en niet gaat pielen met een return false.

Wat betreft luiheid. Ach, in veel gevallen is het simpelweg efficiëntie en professionaliteit. In veel gevallen wilt een klant simpelweg een werkend product binnen een bepaalde tijd/budget. Dan moet je soms concessies doen en dingen eenvoudiger aanpakken in plaats van de mooiste manier.

En als je even goed leest, dan weet je dat ik het had over teveel/overbodige checks. Dat is niet robuust, dat is tijd-/geldverspilling.