Posts by FangorN

Dat motto dough:

Map Pedometer - How far did you go?

I see what they did there (or maybe that's my own twisted mind).

Er was al wat ophef naar aanleiding van dit nieuwe spel. Zo waren ziekenhuizen en andere openbare gebouwen (bibliotheken?) niet zo blij met de mensen die dit soort ruimtes overspoelden, want hier waren monsters ook te vinden. Zelf claimde Nintendo volgens mij dat deze beestjes zich niet zouden ophouden op gevaarlijke plaatsen (zoals op het spoor ofzo).

Reken er maar op dat Nintendo alles juridisch gezien allang dichtgetimmerd heeft.

Het wordt tijd dat er in Nederland een zero tolerance beleid wordt ingevoerd voor mobiele telefoon en smartphones in het verkeer.

Voor de komst van spellen zoals deze vormde dit al een groot gevaar, met de introductie van dit spel is het gewoon wachten op de eerste verkeersdode.

En wat als je nu meerdere stukken data / arrays wilt dumpen? Dan is deze functie niet bruikbaar omdat deze stopt na de eerste dump.

Functies dienen flexibel en herbruikbaar te zijn. In dat opzicht zou het misschien een verbetering zijn om een optionele tweede parameter mee te geven die aangeeft of het programma verder moet gaan / moet stoppen met het uitvoeren van code.

<?php
function myDump($data, $stop=false) {
    // do something to dump $data
    // ...
    if ($stop) {
        exit;
    }
}
?>

Persoonlijk zet ik zelf altijd (tijdelijk) exit's en die's in code zelf, meestal na een of meer dumps. Dit omdat het niet echt de taak is van een functie voor het dumpen van data om de executie van het programma te stoppen. Dit zijn echt twee verschillende taken en horen dan ook eigenlijk niet thuis in een en dezelfde functie...

Daarbij is het rechtstreeks naar het scherm dumpen van data zonder escaping om eerder genoemde redenen (en aangetoond met bijbehorend voorbeeld) niet veilig.

En vervolgens doe je een regexp match ofzo om te zien of de links die aanwezig zouden moeten zijn ook daadwerkelijk aanwezig zijn?

Maar dat zegt nog steeds niet of de link ook zichtbaar is op de pagina - deze kan immers tussen <!-- html commentaar haken --> staan of <div style="display: none;">verborgen worden</div> :).

Het aanwezig zijn van de link in de source biedt dus geen absolute garanties dat deze ook zichtbaar / aanklikbaar is.

Maar misschien is dit een iets te paranoide benadering. Wel denk ik dat het lastig is om dit geautomatiseerd te controleren.

Ben benieuwd hoe dit onder de motorkap werkt.

Hoeveel verschillende machines controleren de sites in kwestie? Wanneer dit één vaste machine (met vast IP) is en je de pagina's op vaste tijden scraped kun je deze checks natuurlijk makkelijk omzeilen ;).

Zoals je in dat voorbeeld kunt zien verschaf je alle informatie (opmaak, legenda, iconen en locaties) zelf. Google Maps is slechts het "platform" waarop dit alles wordt weergegeven.

Indien je een soort van interactieve Google Map wilt maken zul je hier denk ik zelf een soort van beheerkant aan moeten programmeren die ook dingen kan onthouden (bijvoorbeeld via een database).

Tenzij Google Maps zelf functionaliteit heeft om dit soort informatie (centraal) op te slaan zal een "HTML script" niet toereikend zijn omdat HTML niet interactief is (in ieder geval niet op de wijze waarbij informatie onthouden wordt).

Zoekmachie
Voldoen

Niet zeker of ik proofreading als voorstel heb toegevoegd :).

Maar waarom is je SEO dan minder goed? Dit komt toch enkel doordat de toevoeging 301 (HTTP status Moved Permanently) ontbreekt?

Voeg deze overal toe en kijk hoe dat voor je uitpakt als de rest van de RewriteRules hun ding doen?

Je zegt ook:
if(isset($_POST['submit'])) {

Het is in het algemeen niet zo'n strak plan om te controleren op de name van een submitbutton om vast te stellen dat er een formulier gesubmit is. En in dit geval gaat dit ook niet werken omdat je niets POST.

In dit geval ben je geinteresseerd in $_GET['search'] en vooral als deze niet leeg is.

Een eenvoudige oplossing zou dus het vervangen van
if(isset($_POST['submit'])) {
door
if (empty($_GET['search']) === false)
zijn.

Uhm, dus als je op het subdomein www zit dat je dan naar example.com wordt doorgestuurd? Is alles (verder) https?

Daarom is het ook aannemelijk dat er (nog) iets anders speelt. De RewriteRules doen volgens mij gewoon hun ding. Zoveel geeft de topicstarter ook aan: lokaal werkt dit wel, maar online niet. Er worden verder ook geen details over de host gegeven, maar daar zou ik eens wat nader naar gaan kijken...

Nergens geeft topicstarter ook een voorbeeld van hoe deze de pagina's aanroept. Wanneer je URL een trailing slash bevat (/game/, /game/een/, /game/een/twee/, /game/een/twee/drie/) dan krijg je mogelijk niet het gewenste resultaat.

Los hiervan, meerdere ingangen in je applicatie creëren is doorgaans niet zo'n verstandig plan. Niet vanuit security, en niet vanuit efficiency (met meerdere ingangen is er bijna onvermijdelijke overhead doordat je dezelfde dingen dubbel, driedubbel, of meerdere keren uitvoert).

Dus los vanuit het feit dat de RewriteRules gewoon zouden moeten werken (en het is nog steeds interessant om uit te zoeken waarom dit niet werkt) zou je er misschien beter aan doen om je ontwerpstrategie aan te passen.

Speel eens na wat er gebeurt als je http://subdomein.domein.be/ intypt.

Volgens mij wordt je twee keer geredirect. De eerste keer vuurt de eerste RewriteRule omdat je niet op https zit. De tweede keer (na de initiële redirect) vuurt je tweede RewriteRule omdat je niet op het www-subdomein zit.

Ik zou zeggen, om je probleem op te lossen: verwijder regel 3 en 4?

Tenzij op sommige subdomeinen HTTPS uit staat en op andere aan staat ofzo? Je zou dan voor alle subdomeinen een expliciete RewriteRule kunnen maken (of twee lijsten maken: subdomeinen met en subdomeinen zonder HTTPS), of de suggestie van @Ferhat.Remory volgen (het beheer in PHP onderbrengen).

Voor sommigen spreekt een textbased spel nog tot de verbeelding, voor anderen wellicht niet :).

Mogelijk ben jij niet het type dat een boek leest maar liever de film kijkt? Dit zal per persoon verschillen.

Maar inderdaad, als ergens weinig variatie in zit wordt/is het al snel eentonig. Maakt eigenlijk weinig uit hoe je dit verpakt.

Citaat van stijnhau

Het meeste geef ik je gelijk in enkel die seesion_start niet oùdat als je die class include je sessies wilt gebruiken.
Anders moet je die class niet includen.
Ook is er kan ik niet echt een reden bedenken om dit niet rechtstreeks te wensen.

De class verzorgt de afhandeling /verwerking van sessie-opslag. Dit alles gebeurt onder water. Wanneer je session_-functies aanroept of $_SESSION gebruikt heb je er geen weet van hoe dit achter de schermen geregeld wordt en dit hoeft ook niet want dit is in zekere zin abstractie. Wat mij betreft is het dan ook niet aan de klasse om bij het instellen van het type afhandeling van sessies het startsignaal te geven voor het starten/voortzetten van een sessie zelf.

Vergelijk het met de default implementatie van de sessionhandler: daar roep je ook altijd eerst session_start() aan. Pas je deze default session handler aan dan zou dat voor de overige code niet uit moeten/mogen maken. De session handler zelf zou dan ook niet eigenhandig een sessie moeten starten, deze schrijft enkel voor hoe een en ander administratief (en onder water) wordt afgehandeld.

Session handlers zouden ook "vrij inwisselbaar" moeten zijn zonder dat deze van invloed is op andere code. Ook om die reden hoort session_start() niet in de handler zelf thuis: dit zou namelijk inhouden dat je voor sommige implementaties session_start() in andere code zou moeten toevoegen en in andere implementaties achterwege kunt laten. In dat geval zou de ene handler niet zonder meer uitgewisseld kunnen worden voor een andere.

Long story short: het starten/voortzetten van een sessie regel je simpelweg niet in de handler zelf omdat dat niet de taak is van een session handler :p.

Oh, nog een argument: je zou sessie-instellingen dan ook in de constructor moeten opnemen/doorgeven (of moeten instellen voordat je een object creëert) omdat je deze voor het starten van de sessie moet instellen. Hiermee leg je een additionele eis op aan de volgorde waarin dingen geregeld moeten worden. Het wordt dan allemaal steeds minder transparant/intuïtief en gaat ook voorbij aan de scope van wat een session handler zou moeten doen...

Citaat van wimmpie

Bijvoorbeeld als je uit een grote tabel, 1 persoon moet gaan selecteren op ID.
Als je dan LIMIT 0, 1 op het einde toevoegt, stopt je query dan zodra hij de eerste heeft gevonden?

Maar een id is uniek, dit impliceert dat er maar (maximaal) één record is. LIMIT 0, 1 voegt dan waarschijnlijk niet zoveel toe (daarnaast staat dit nogal suf, alsof je jezelf ervan wilt verzekeren dat je ook maar echt één record selecteert). Je zou dit natuurlijk altijd kunnen toetsen door het uitvoeren van benchmarks maar ik denk niet dat LIMIT je query sneller maakt, andere zaken hebben meer invloed op de snelheid.

Iets wat redelijk doorslaggevend is bij de zoeksnelheid is of (de combinatie van) de kolom(men waarmee je zoekt) geïndexeerd is. Een primaire sleutel heeft automatisch een index dus daarop/daarmee kun je altijd snel zoeken. Veel sneller dan SELECT <whatever> FROM <tabel> WHERE id = <index van geindexeerde kolom> wordt het niet.

Om inzage te krijgen wat MySQL doet en hoe deze tabellen aan elkaar fietst kun je SELECT statements vooraf laten gaan door EXPLAIN. Vervolgens krijg je een tabelletje die je vertelt van welke keys of andere hulpstukken MySQL gebruik maakt om queries vlot uit te voeren. Indien je trage queries hebt loont het de moeite om eens via EXPLAIN te kijken waar volgens MySQL de bottleneck(s) zit(ten).

Ook de keuze van een engine kan je hierbij helpen. In een database met enkel MyISAM (default engine) tabellen hangen deze als los zand aan elkaar. Je kunt geen foreign keys naar een andere tabel definiëren en dus ook niet op die manier meeliften op de index die daar mogelijk op bestaat geloof ik. Om meerdere redenen is het verstandig om InnoDB als engine te gebruiken als je van plan bent om een relationele database te bouwen. Indien je gebruik maakt van de voorzieningen van InnoDB kun je ook redelijk eenvoudig performancewinst meepakken.

Citaat van stijnhau

Dit lijkt me allemaal nogal complex.
http://culttt.com/2013/02/04/h…p-sessions-to-a-database/
Sessie rechstreeks opslaan in de database.

Dat artikel, evenals het artikel waar daarin naar verwezen wordt, is interessant maar er zijn wel enkele "caveats", gotcha's en (mogelijk) enkele regelrechte fouten waar je op moet letten.

Indien gewenst kan ik (hier of via PM) inhoudelijk nog veel meer over zeggen, maar het voornaamste wat mij tegenstaat in de bovenstaande implementatie is het volgende:

Ik houd er niet van als mijn klasses "op scherp" staan, in die zin dat er allerlei zaken automatisch worden uitgevoerd bij de creatie van een object. Wanneer een object aangemaakt wordt zouden er enkel zaken geïnitialiseerd moeten worden, maar NIET uitgevoerd! Na afloop van de initialisatie van een object zou dit object enkel "klaar voor gebruik" moeten zijn, maar verder nog niets "gedaan" moeten hebben. In de constructor van het object gebeuren er twee dingen die ik op een andere manier en op een andere plaats zou aanpakken / regelen:

• de start van een sessie
• het opzetten van een database-connectie

Ik wil zelf bepalen wanneer ik mijn sessie start. De sessie-handler zou enkel in de implementatie van het sessie-management moeten voorzien, maar niet eigenhandig moeten besluiten wanneer de sessie wordt gestart. Ik zou session_start() dan ook verwijderen uit de constructor.

Daarnaast lijkt het mij beter dat je een bestaande database-connectie doorgeeft aan de constructor. Het is niet de taak van de sessie-handler om een andere/tweede connectie op te zetten met een database... Daarnaast is het opzetten van een (tweede) connectie een dure operatie en kan mogelijk voor problemen zorgen met de ondeelbaarheid van querybatches (transacties).

En tot slot (observatie): het hele doel van die class is dat deze het sessie-management onder water regelt en dat je sessie-gerelateerde code op de ouderwetse manier blijft gebruiken (de aanroep van session_-functies en het gebruik van $_SESSION). Het is dus eigenlijk helemaal niet de bedoeling dat je iets doet via het object van die klasse, het object zou dan ook niet beschikbaar moeten zijn.

Initialisatie van deze functionaliteit zou er dus min of meer als volgt uit moeten zien:

<?php
// zet hier ergens EENMALIG je database connectie op
// $db = ...


// laad je custom session handler ZONDER $obj = new ...
// de instantie dient immers niet rechtstreeks benaderbaar te zijn
// geef database-object door aan de constructor
new MySession($db);


// start sessie op de oude manier
session_start();


// nu kun je $_SESSION en session_-functies gebruiken zoals voorheen
// ...
?>

Staat alles in de root van je webdirectory? Misschien is het toch handig om een expliciete RewriteBase toe te voegen.

Misschien gaat er iets mis met URL encoding/decoding, want &sub; is een HTML entity. Mogelijk probeert het systeem iets foutief te repareren.

Misschien zijn er andere, en niet zichtbare (of die van jezelf, in een hoger gelegen directory), rewriterules actief?

Heb je al eens $_GET gedumpt in index.php, game.php et cetera?

Zolang je niet weet wat de oorzaak van een probleem is is het in het algemeen ook verstandiger om hier geen aannames over te doen.

Citaat van wimmpie

Waarom zijn online games altijd multiplayer?

Laat ik deze vraag met een vraag beantwoorden: waarom zou je een single player online spel maken? ik bedoel, wat zou het punt daarvan zijn. Online is nagenoeg altijd synoniem met multiplayer.

De indruk (en een indruk kan altijd verkeerd zijn) van "crime games" die ik altijd heb gehad is dat deze doorgaans niet fantastisch geprogrammeerd waren en nogal infantiel overkwamen. Dit gebrek aan kwaliteit kan gevolgen hebben voor de "stickyness" of "(her)speelwaarde".

Ik denk dat "gameplay" de belangrijkste factor is - hoe plezierig is het om te spelen. Hierbij bedoel ik niet onderhoudend of gemakkelijk, maar misschien een combinatie van al dit soort dingen. Backstory en gelikte graphics leggen het na verloop van tijd hiertegen af. Een spel moet een zeker je-ne-sais-quoi hebben om het te blijven spelen (noem het een "soepele speelervaring", wellicht is dat nog de beste verwoording van "gameplay"). Of je bent het na verloop van tijd "gewend" (ook wel "verslaafd" in de volksmond).

Daarnaast is de keuze tegenwoordig veel groter en de aandachtsspanne en doorzettingsvermogen van het publiek aanzienlijk korter. En mogelijk worden veel meer psychologische inzichten losgelaten op een spel bij de ontwikkeling ervan. De gaming industrie is ook, op een heleboel manieren, veel volwassener geworden in de loop der jaren.

Waarom stuur je niet gewoon alles door naar index.php (single point of entry in je applicatie) die dan de REQUEST_URI inspecteert en code inlaadt? Waarom deze brei van RewriteRules?

Je zegt "het werkt niet". Waar blijkt dit uit? Krijg je foutmeldingen?

Ook lijken index.php en game.php structureel ongeveer hetzelfde te doen, waarom heb je hier dan toch twee bestanden (twee ingangen in je applicatie) voor gemaakt?

Wat @ThomasBlom zegt lijkt mij in ieder geval verstandig: indien er een match is met het patroon van een RewriteRule, voer deze dan uit en stop verdere matching.