Ik ben het 110% eens met deze regeling.

De toestellen die je bij zo'n abonnement "krijgt" -het betreft vaak redelijk nieuwe of zelfs de allernieuwste modellen- kosten meestal honderden euro's. Elk weldenkend mens snapt dat slogans als "0 EURO" of "X EURO PER MAAND" meer betekenen dan enkel dat, of gewoon niet waar kunnen zijn. Vooral als je eens kijkt naar wat zo'n toestel los kost.

Tegenwoordig lees ik steeds vaker dat steeds grotere aandelen van bovolkingsgroepen (tieners, twintigers, (jonge) gezinnen) leven met een schuld. Alsof dit de normaalste zaak van de wereld is. Het wordt ook met de paplepel ingegoten op deze manier. Is het belangrijker dat je het laatste speeltje hebt dan dat je financiële administratie op orde is? In het kader van "als je haar maar goed zit" :/.

We moeten af van de mentaliteit dat het "OK" is om dingen te kopen waar we eigenlijk het geld niet voor hebben. Tijd om de tering weer naar de nering te zetten.

Citaat van Ferhat.Remory

debugcodes

Maar die zijn voor bij ontwikkeling of interne administratie, daar moet je een eindgebruiker niet mee vervelen vind ik.

Stel dat jij als developer een site ontwikkelt. Dan wil jij exceptions en dumps en logs en de hele santekraam. Maar uiteindelijk zou een eindgebruiker enkel een neutrale foutpagina met weergave / meegeven van een HTTP status code (404, 500 of wat heb je daar) moeten zien, wellicht met de toevoeging dat als het probleem aanhoudt je beter met iemand (technische dienst) contact op zou kunnen nemen. Ondertussen is er dan ook al het een en ander (onder water) gelogd.

Citaat van Jesse

later moet deze code gaan verwijzen naar de pagina met de mogelijke oplossing

Dit zullen nog steeds redelijk generieke pagina's zijn. Als je een standaard fout hebt, is een standaard oplossing ook toereikend. Maar steeds vaker ontstaan volgens mij niet-standaard fouten in niet-standaard situaties.

In bijna alle gevallen waarin ik een probleem heb in Windows dan heb je hier mogelijk een knowledgebase / wizard voor die je door kunt klikken om tot een oplossing te komen die bijna altijd (voor mij althans) niets oplevert.

Laat ik het anders zeggen, ik denk dat een ietwat gevorderde gebruiker hier weinig aan heeft omdat deze tegen andere dingen aanloopt dan een "average everyday user".

Je kunt beter je software robuuster maken die wegstuurt van dit soort niet-oplosbare situaties als je het mij vraagt. Wat wordt beschreven is dat er nu een soort van catering komt voor als een ramp zich heeft voltrokken :).

Ik zou liever een stabiel systeem willen hebben dan een nette(re) foutpagina.

Opmerkelijk dat zij hier op deze manier in investeren. Verwachten ze meer bezoekers op foutpagina's dat ze zich gedwongen voelden deze te pimpen?

Citaat van T.Nijborg

Ow had ik dat maar geweten jaren geleden :P, ik dacht serieus dat het niet mogelijk was

Als alles is weggekieperd wordt het lastig, maar dat was dus niet het geval.

Euh, heb je dus je databases kunnen terughalen?

@Ferhat.Remory mja komt idd neer op uitvogelen waar de vorige versie van WAMP/MySQL haar bestanden wegschreef en dan kijken of daar nog iets van over is. Recovery software is wellicht een beetje optimistisch maar mogelijk het proberen waard. Ik denk dat je er wel vanuit kunt/moet gaan dat weg=weg :/.

Of misschien heb je nog een savepoint van je OS die teruggedraaid kan worden. Maar dan ben je mogelijk voor- en achteruit aan het rijden in de modder en kom je alleen maar vaster te zitten :).

Maar @wimmpie was je alleen maar lokaal aan het ontwikkelen en applicaties aan het draaien? Zijn deze nergens anders meer actief? Meestal slingeren er her en der toch nog wel kopieën rond?

Heb je de directories verkend? Mogelijk bestaan dit soort data-mappen nog. Ik weet ook niet of WAMP bijvoorbeeld zomaar je htdocs map wegmietert, hier kunnen ook allerlei werkbestanden in staan. WAMP zal toch wel een beetje intelligent zijn wat dat betreft? Heb je geprobeerd via de DOS prompt een connectie te maken met je MySQL databases? Kijk eens welke er nog zijn met "SHOW DATABASES". Dit zegt trouwens ook niet alles. WAMP kan namelijk geconfigureerd zijn voor de nieuwe setup, terwijl de oude nog ergens bestaat.

Het beste wat je kunt doen is even door de directories heenploeteren, bijvoorbeeld /wamp/bin/mysql/. Indien hier meerdere versies in staan heb je een waterkansje dat je datamap hier ook nog staat - in de oudere MySQL versie van de twee. Vervolgens zul je even secuur te werk moeten gaan met het formuleren van een strategie voor het terughalen van deze gegevens. Eerst denken, dan doen :).

NOTA BENE: als je in /wamp/bin/apache/ en /wamp/bin/php/ meerdere versies hebt staan is dit ook een indicatie dat de deinstallatie niet volledig was en er dus zich mogelijk nog ergens data bevindt!

En ja backups backups backups.

Zelfs als je WAMP gebruikt is het zinnig om dit regelmatig te doen. Ik heb het wel eens meegemaakt dat WAMP (of een onderdeel) crashte en dat toen de bestanden waarin de structuur van mijn tabellen stond corrupt was geraakt. Dit heb ik nog enigzins kunnen herstellen maar ja. Ben wel genezen van mijn naiviteit van "kan toch weinig fout gaan".

@Luc volgens mij krijg je dan elke keer dezelfde "random" posts. Ook wordt je subquery dan nogal zwaar?

Misschien zou je dit ook op een andere manier kunnen oplossen (caching? redundant opslaan?) maar je zou je ook kunnen afvragen wat je nou eigenlijk met zo'n query wilt...

Even los van wat je probeert te bereiken, wat is het *nut* van deze query? Als het de laatste post van alle individuele gebruikers zou zijn zou ik dit nog enigzins snappen, maar een willekeurige?

De C-schijf is je systeemschijf. Ik zou hier persoonlijk nooit spellen op zetten. Ook applicaties en/of werkbestanden zouden eigenlijk op een ander station moeten staan. Dit scheelt je een hoop ellende mocht er ooit iets met je OS misgaan, je kunt dan in het meest ideale geval je C-schijf helemaal leeggooien en een clean install doen of een image terugzetten.

Overweeg een snelle (iig leessnelheid)/grote dedicated SSD puur en alleen voor spellen.

Citaat van Aaron

mooier

beauty is in the eye of the beholder

Wat jij mooi(er) vindt, vind iemand anders wellicht lelijk(er).

Use the Google Luke!
Zoekopdracht: php resizing animated gif

eerste resultaat

Use the Google Luke!
Zoekopdracht: css border ellipse

vierde resultaat

Dit is geen script maar een systeem (een verzameling van "scripts").

Heb je ook een bestaande producten database, of een webshop of wat dan ook, of heb je nog helemaal niets? Dan heb je wellicht ook een producten systeem nodig.

En heb je al een soort van ledensysteem?

Dit zijn dus potentieel drie systemen die gebouwd moeten worden. Een soort van kinder surprise dus (maar dat zijn drié wensen!).

Citaat van elias11

Het moet HTML , CSS en Javascript bevatten.

Waarom? Dit soort technieken zijn een middel, geen doel. Als deze "applicatie" interactie heeft door een besturing via toetsen dan kun je waarschijnlijk moeilijk heen om JavaScript, maar dat iets op voorhand "JavaScript zou moeten bevatten" lijkt mij een beetje stug.

Citaat van elias11

Ik ga iets maken waarbij ik een poppetje van Superman kan laten bewegen met de toetsen.

Wat je applicatie zou moeten doen kun je opstellen los van techniek. Dit heet ook wel een functioneel ontwerp. Dit is de "klus". Daarna kies je op grond van de klus je gereedschap (technieken zoals JavaScript et cetera).

Niet andersom :p

Heb je voor jezelf al uitgedacht hoe je applicatie er uitziet / wat deze zou moeten doen? Interfaces? Scenario's? Of gewoon beschrijvingen in platte tekst?

Dat Superman moet rondspringen op je scherm vertelt mij niet direct wat er in JavaScript zou moeten gebeuren :).

Citaat van K.Rens

De komende tijd zullen wij deze scripts nakijken en updaten indien nodig.

En testen? :p

Citaat van K.Rens

Dit om de kwaliteit te waarborgen.

Is dit ook gebeurd / gebeurt dit ook met de hier reeds aanwezige scripts?

Ik lees op hun site dat dit ook mogelijk betekent dat de site ophoudt met bestaan. Als het bovenstaande toch een soort van "reddingsoperatie van content" is, is er dan wellicht ook een mogelijkheid om andere content (zoals tutorials, ik geloof dat zij dat "WIKI's" noemen) ergens onder te brengen? Bijvoorbeeld in een blog?

Ben ook benieuwd hoe het dan zit met auteursrecht enzo

Dit geld hadden ze wellicht beter kunnen steken in QA van hun eigen software :].

Uhm, gewoon altijd real_escape_string() in combinatie met single quotes in je querystring.

WEL veilig:

<?php
$res = mysqli_query(
    $dbLink,
    "SELECT whatever FROM table WHERE id = '".mysqli_real_escape_string($dbLink, $someVar)."'"
);
?>

NIET veilig:

<?php
$res = mysqli_query(
    $dbLink,
    'SELECT whatever FROM table WHERE id = '.mysqli_real_escape_string($dbLink, $someVar)
);
?>

Nog beter zou een OOP variant van het eerste fragment zijn, uiteraard.

En om je een voorbeeld te geven van real_escape_string() is geen wondermiddel:

Gegeven het volgende codefragment:

<?php
// Connect etc.
// ...


$id = isset($_GET['id']) ? $_GET['id'] : false;


if ($id === false) {
    ?><p>No id supplied.</p><?php
} else {
    $res = mysqli_query(
        $link,
        'SELECT * FROM table WHERE id = '.mysqli_real_escape_string($link, $id)
    );
    // etc.
}
?>

Is deze query veilig?

Het antwoord is NEEN.

mysql_real_escape_string() escaped alleen maar indien er iets te escapen valt.

Als je voor je id het volgende invult:

41 OR 1=1

Dan doet real_escape_string() hier NIETS mee. Hiermee kun je dus een geslaagde SQL injectie uitvoeren.

Dit is de reden waarom je real_escape_string() ALTIJD zou moeten gebruiken in combinatie met quotes. Het een is simpelweg niet veilig zonder het ander.

Nu heb ik hier lang en breed over na zitten denken (en ben er eigenlijk nog steeds niet helemaal uit). Stel nu dat je je ook bedient van input filtering (de andere helft van filter input, escape output). Wat nu als je er eerst voor zorgt dat je alleen de query uitvoert indien $_GET['id'] een numerieke waarde heeft? Je zou dan escaping geheel achterwege kunnen laten (al zou ik dat waarschijnlijk niet aanbevelen :)). Voor beide aanpakken of een combinatie hiervan valt iets te zeggen. Zaak is en blijft dat je altijd code schrijft waarbij je aanneemt dat ALLE externe DATA een potentieel risico vormt en deze ook als zodanig behandelt.

Indien je een wrappertje schrijft voor de normale werkwijze in MySQLi (zonder prepared statements) zou dit er bijvoorbeeld als volgt uit kunnen zien:

<?php
$db->query(
    "INSERT INTO Websites (Naam, GebruikersID) VALUES (
        '".$db->escape($_POST['sitenaam'])."',
        '".$db->escape($_SESSION['gebruikersID'])."'
    )"
);
?>