Kwaliteit vs Kwantiteit op ISPam.nl

Voor ISPam.nl heb ik een aantal regels voor de redactie. De belangrijkste is waarschijnlijk dat er elke werkdag om 8:00 en 8:10 uur twee artikelen worden gepubliceerd. In principe dus niet meer dan twee artikelen, maar ook niet minder. Het doel van ISPam.nl is om de sector zo goed mogelijk op de hoogte te houden van de laatste relevante ontwikkelingen.

De vraag die ik me zelf daarbij stel is in hoevere ISPam.nl met de zelfde berichtgeving als grotere, algemenere technische nieuws websites zoals Tweakers.net, Webwereld, Automatiseringgids, etc moet komen. Om een compleet beeld te geven van relevante ontwikkelingen is het verleidelijk om het nieuws van deze grotere collega’s ook te publiceren.

Echter heeft dat ook een keerzijde, want ookal richt ISPam.nl zich op een niche, echter is in veel gevallen het niveau van de berichtgeving van deze websites al zodanig dat een zelfde bericht op ISPam.nl niet veel toevoegd, behalve dan misschien enkele inzichten die specifiek over ISP’s gaan. Ik neig er daarom naar om nieuws dat al door de grote technische nieuwswebsites is verslagen niet langer op ISPam.nl te verslaan, tenzij het zodanig hosting specifiek is dat het niet mag ontbreken op ISPam.nl. Dus niet langer voor kwantiteit maar in plaats daarvan zuiver voor kwaliteit te gaan.

Een ander punt waarvan ik hoop dat dit de kwaliteit van ISPam.nl ten goede zal komen is om altijd wederhoor te doen, conform een “comply or explain” principe, waarbij er een reden moet zijn om niet aan wederhoor te doen, in plaats van andersom. Hier ben ik de afgelopen dagen dan ook al mee begonnen. Zo heb ik RapidShare om een reactie gevraagd in een kwestie over het niet gaan controleren van uploads van gebruikers, een belrondje over de stroomstoring in het NIKHEF datacentrum en eveneens een belrondje over de domeinlock bij DNS BE vandaag. Het is even wennen om continue vragen te bedenken en die aan betrokkenen voor te leggen in plaats van zo nu en dan, maar het is wel leuk.

Nu is het te hopen dat deze nieuwe werkwijze ook zal leiden tot meer kwaliteit, uiteindelijk meer bezoekers en natuurlijk adverteerders. Als ik dit artikel bij De nieuwe reporter mag geloven gaat dat lukken!

Ik zoek overigens nog een freelance sales of account manager, uiteraard gewoon gewoon uurtje-factuurtje en indien gewenst kan een bonus ook deels, maar dat heeft niet mijn voorkeur. Wie geintresseerd is kan mailen naar info@xcat.nl of bellen naar 0251 714 029.

Van Prototyping naar DesignInDemo

In mijn beleving zijn er twee manieren om software te ontwikkelen. De eerst methode is gewoon beginnen en terwijl het bouwen bepaal je hoe het eindproduct er uit komt te zien binnen de mogelijkheden en beperkingen die de ontwikkelingomgeving die je gebruikt heeft. De andere methode is om op papier te bedenken wat je wilt, waarbij je de (theoretische) beperkingen van de ontwikkelingomeving vooraf incalculeert.

In het verleden heb ik geprobeerd om software te ontwikkelen op basis van design en dat ging vrijwel zonder uitzondering altijd fout, want de theorie staat te ver af van de praktijk. Bij die projecten viel ik dan ook altijd terug op de ontwikkeling op basis van het simpelweg bouwen. Nu mogen beide werkwijzen tegenstrijdig lijken, maar ze vullen elkaar in principe aan, mits je eerst simpelweg begint te bouwen en dan het papieren design maakt, dit noemen we Prototyping.

Voor wat simpelere projecten is een volledig prototyping proces naar mijn idee te veel van het goede. Zelf heb ik bij projecten die ik nu zelf nog (deels) doe gemerkt dat je zelfs vanuit een prototype of demo dat als final wordt gebruikt het design er langzaam kan inbrengen.

In een website die ik heb regelde tot nu toe elke pagina zijn eigen query om de gegevens van een bepaalde winkel op te halen, dat is met recht niet bepaald een wenselijke situatie. Dus heb ik dat vervangen met de functie getWinkel($id), die simpelweg het resultaat van een dergelijke query teruggeeft.

Er zit echter één nadeel aan dat er bij bijvoorbeeld een join altijd één extra query nodig is. In overzichten wordt het echter nog erger, omdat getWinkel($id) maar één resultaat teruggeeft en daarmee 100 queries moet uitvoeren.

Daarvoor heb ik nu ook een oplossing, simpelweg door preloadWinkel($winkels), die alle id’s in $winkels ophaalt uit de database en de data alvast klaar zet, maar ook als er rechtstreeks via getWinkel() de gegevens van een winkel worden opgevraagd, gaat het via preloadWinkel(), om te voorkomen de query op meerdere plaatsen komt te staan.

De volgende stap is om winkel tot een Class (object) te maken, terwijl er toch backwards compatability is. De oplossing daarvoor is ook simpel, bij de class Winkel komt een functie data() en zodra getWinkel wordt aangeroepen, maakt deze een Winkel object aan, en doet het return $winkel->data(). Uiteraard is het $winkel object via de eigen ingebouwde preloader (Data Access Object) al geladen, waardoor de overhead gelijk blijft en het systeem prachtig object georienteerd wordt.

Vanuit de werkende demo kun je op deze manier eenvoudig een versie maken, zoals die er idealiter op de tekentafel zou uit komen te zien.

Van prototyping naar DesignInDemo

Nu ook Virtual Private Servers (VPS) vergelijken op ISPGids.com

Het is amper een week geleden dat ik schreef dat er op ISPGids.com ook colocatie, dedicated en VPS pakketten vergeleken moeten kunnen worden, zoals dat tot dan toe ook al mogelijk is voor webhosting. Ik ben er daarom eens goed voor gaan zitten en vanaf vandaag is het dan zover. ISPGids.com heeft een nieuwe VPS-module waar ISP’s hun VPS pakketten in kunnen vermelden. Op dit moment is het overzicht van de VPS-pakketten nog niet live, omdat deze nog goed moet worden doorgetest én er eerst door verschillende aanbieders een paar pakketten moeten zijn toegevoegd om de module dan met een knal écht live te laten gaan.

Onder de motorkap van de VPS-module zit een basis product module, waarmee het mogelijk is om ook andere pakket vergelijkers te maken, zoals backup, colocatie, dedicated, ssl certificaten, streaming, etc. Al zit er nog wel het nodige werk aan het bouwen van een nieuwe module, om wille van flexibiliteit maar ook om de module zelf niet te complex te maken. De feitelijke bouw van de module koste me ongeveer één werkdag, al kost het bedenken van alle ins en outs van de module zelf wel wat meer tijd, maar ik heb het hier over de kale bouw.

Los van het feit dat ik het nog steeds erg leuk vind om zelf uitdagende projecten te programmeeren, past het natuurlijk niet in mijn “outsource alles” strategie. Alleen in dit geval weet ik zo goed als zeker dat het zelf programmeren van de module mij minder tijd kost, dan enkel het uitschrijven van het concept. En dat is dus nog los van de tijd van het aanbesteden van het werk op eLance, het aansturen van de programmeur en het implementeren en finetunen van de module in ISPGids.com.

Om dus echt tijd winst te halen moet ik echt alles uitbesteden aan een derde partij, dus niet alleen de feitelijke bouw maar ook het concept. Zouden buitenlandse outsourcing/offshore partners daar geschikt voor zijn of moet ik dan toch kijken naar Nederlandse partners?