Sociale verantwoordelijkheid

Als webdesigner of -developer heb je een zeer grootte verantwoordelijkheid tegenover jouw klant. Om dit beter te kaderen schets ik twee voorbeelden. 1ste voorbeeld: een prospect komt naar jou toe en verteld zijn idee. Naarmate het gesprek vordert begrijp je dat dit idee geen kans op slagen heeft. Dit weet je al dan niet door praktijk ervaring.

Wat is de volgende stap die jij zet? Wetende dat jij nu optreed als zijn huidig consulent op de zaak. Neem je het project aan, verdien je dan nog snel wat extra en laat je de arme sukkel in zijn onwetendheid want misschien dat het toch slaagt, doet het dat niet dan is het immers toch niet jouw fout?

Of, vertel je hem in alle eerlijkheid hoe jij staat tegenover dit project met de mogelijke kans op verlies van een extra inkomst? Mijn antwoord: ja. Je verteld hem in alle eerlijkheid hoe jij staat tegenover dit project en dat je de slagingskans zeer laag inschat maar je laat de keus over aan hem om het project al dan niet verder te zetten. Je stelt eventueel ook voor om het project zeer nauwkeurig te volgen en wekelijkse of maandelijkse rapporten te voorzien zodat de klant tijdig het project kan stilzetten. Dit kost hem meer op korte termijn maar zal hem veel geld besparen op langere termijn.

Op professioneel vlak zal dit je op langere termijn meer opbrengen aangezien de klant nu begrijpt dat hij voor jou meer waard is dan wat centen en biljetten en zal er direct voor zorgen dat hij bij zijn volgend idee opnieuw jou zal consulteren omdat hij begrijpt dat hij een eerlijk antwoord zal krijgen. Indirect zorgt dit er voor dat hij jouw professionalisme bij kennissen zal prijzen.

2de voorbeeld en evenwel het tegenovergestelde van het 1ste voorbeeld: een klant komt naar jou toe met een geweldig idee. Een gat in de markt! Je bent supergemotiveerd en het duurt niet lang voor je een goed ontwerp op de tafel kan toveren. Niet veel later staat het project online. Omdat de klant zelf niet veel van het web gebeuren af weet huurt hij jouw diensten in om de website te voorzien van het nodige onderhoud zodat deze “vers” blijft. Omdat jij nu de hoofdverantwoordelijke bent van deze website heb je ook toegang tot de gegeneerde inkomsten die deze website maakt. Naarmate de weken vorderen en jij er hard aan werkt zie je de inkomsten van deze website verdubbelen, verviervoudigen maar jouw uitbetaling blijft ondanks deze situatie en jouw harde werk hetzelfde.

Wat is jouw volgende stap alle legaliteit terzijde? Imiteer je zijn idee onder een andere naam misschien start je zelfs een nieuw bedrijf op die zal optreden als de eigenaar van deze imitatie zonder dat deze direct naar jou verwijst om op deze manier een stuk van de winst op te strijken en omdat je een groot stuk van de koek wilt verwaarloos je de website van je klant gedeeltelijk.

Dit is een zeer moeilijke om een antwoord op te geven en heeft meer iets te maken met je eigen integriteit en morele waarden.

Wat zou jij doen in beide voorbeelden?

Tip: Code & Query optimalisatie

Neem als voorbeeld dit stukje code:

$user = $userTable->find($req->get(‘id’));
$userForm = new UserForm($user);
if ($req->isPost() && $userForm->isValid($req->getPost())) {
$user->save($userForm->getValues());
}
$view->form = $userForm;

De meeste zouden zeggen dat deze code buiten een paar opmerkingen over de validatie goed geschreven is. Wanneer je deze code echter beter gaat bekijken kan je zien dat deze code 2 statussen (ophalen van de gebruiker informatie, wegschrijven van de gebruiker informatie) heeft en zal uiteindelijk 3 queries uitvoeren (het ophalen van de gebruiker informatie word 2 keer uitgevoerd, in de meeste gevallen 1-maal zonder functioneel nut). De oplossing is dan ook redelijk simpel deze code splitsen!

Deel 1 word dan:
$user = $userTable->find($req->get(‘id’)))) ;
$userForm = new UserForm($user);
$view->form = $userForm;

Deel 2 word dan:
$userTable->update($req->get(‘id’), $req->getPost());

Deze code voert 2 functionele queries uit. In het uitzonderlijke geval dat de gebruiker toch iets fout doet stuur je hem gewoon terug met de parameter id in alle andere gevallen spaar je deze extra query uit.

De rol van de bezoeker

Vandaag wil ik het eens hebben over een probleem dat zich stelt wanneer je een community systeem bouwt waarbij de inhoud afhankelijk is van de groep waarin de gebruiker zit. Al snel stoot je op ‘de bezoeker’. Deze persoon is niet aangemeld dus welke inhoud toon je? En hoe ken je inhoud toe bestemd voor de bezoeker?

Populaire open-source systemen zoals Drupal lossen het als volgt op: zij hebben nl. een anonymous user rol deze word de standaard groep voor personen die niet zijn aangemeld (via een query halen ze de groep op met id 1 waarvan zij weten dat dit een gereserveerde rol is) enig nadeel je kan deze niet verwijderen of bewerken uit de database want hoe weet jouw applicatie dan weer welke groep hij moet toekennen aan bezoekers? Je zou het als volgt kunnen oplossen: een extra veld voorzien dat vraagt of de groep bestemd is voor bezoekers. Maar dan is er weer dat dit bij elke nieuwe groep komt te staan tenzij je een extra query uitvoert, maar dat is slordig. Is er geen simpelere oplossing? Ja!

Jouw bezoeker heeft geen groep dus geef de inhoud voor jouw bezoeker ook geen groep ofwel gebruik als id 0. Geen extra veiligheid die moet worden ingebouwd om er voor te zorgen dat de gebruiker de bezoeker groep niet kan verwijderen want deze is er nl. niet. En voor wie het waterval principe(1) toepast is er ook geen probleem want 0 vormt dan het wortel element. Maar wacht, hoe verander ik dan de naam? Simpel, stop de naam in je configuratie bestand en laat de eindgebruiker deze behouden of veranderen naar wat leukers.

Bij het aanmelden is er sowieso geen probleem want dan is er een groep toegekend al dan niet ‘de bezoeker’ groep. Standaard zal er dan één of twee groepen voorzien worden voor aangemelde- en speciale leden. Deze kunnen zonder probleem worden verwijderd op voorwaarde dat deze 1) niet de enigste overblijvende groep is 2) deze niet de groep is waarvan jij momenteel deel uitmaakt 3) jouw groep beschikt over de toelating om zich aan te melden op het administratief gedeelte. Deze 3 maatregelen moeten zelf-uitsluiting voorkomen.

Weten jullie een betere oplossing? Laat het dan zeker weten!

1. Een groep erft de eigenschappen van zijn ‘ouder’-groep waardoor deze dezelfde inhoud kan zien als zijn ‘kind’-groep.

Go

De nieuwe programmeertaal van Google die 120k lijnen code compileert onder 10 seconden. De syntax verleent Go van verscheidene talen waaronder C++ en Java en is zoals zij zelf zeggen een dynamische taal met de veiligheid en snelheid van een statische taal. Hoewel Go oorspronkelijk is bedoeld voor de ontwikkeling van systemen en servers is het ook mogelijk de taal te gebruiken voor andere toepassingen. Als proof-of-concept hebben ze een website opgezet.

spdy://ignace.wordpress.com

Velen zullen rare ogen trekken bij het aanschouwen van deze titel maar het is het nieuwste brein-kind van het Chromium team bij Google. SPDY – uitgesproken als SPeeDY – bevindt zich in de netwerk architectuur op de applicatie laag en heeft als doel om het versturen van inhoud over het web te versnellen. De eerste tests zijn uiterst positief aangezien SPDY momenteel 50% sneller is als HTTP. Het uiteindelijke doel is om 200% sneller te zijn dan HTTP dus nog 50% te gaan. Of SPDY uiteindelijk HTTP echt zal gaan vervangen weet niemand op dit punt met zekerheid.

Quote op 15 November 2009

Just remember: you’re not a ‘dummy,’ no matter what those computer books claim.  The real dummies are the people who–though technically expert–couldn’t design hardware and software that’s usable by normal consumers if their lives depended upon it. — Walter Mossberg

Dilbert op 15 November 2009

De grotere foto

Bij de meeste grootse wetenschappelijke uitvindingen die er door de eeuwen heen zijn gebeurd zijn er altijd betwistingen geweest over wie het nu eigenlijk eerst heeft uitgevonden – de geschiedenis boeken staan er vol van. Vaak mond dit uit in een tweestrijd waarbij de ene de andere in diskrediet wil brengen d.m.v. uitspraken of machtsmisbruik. Voor mij en voor vele anderen maakt het niet uit wie het uitgevonden heeft uiteindelijk zolang het maar uitgevonden werd. Moest dit bij mij voorvallen dan zou ik eerder kwaad zijn om het feit dat ik hier niet vroeger ben van op de hoogte gebracht  i.p.v. mij zorgen te maken over wie met de eer gaat lopen want uiteindelijk is hetgeen wij doen slechts ten goede van de evolutie- en het welzijn van de mensheid. En een goede verstandhouding zal er uiteindelijk voor zorgen dat beide partijen hun visies en gedachten kunnen delen wat uiteindelijk zal leiden naar een beter eindproduct dan dat beide partijen zelfstandig hadden kunnen ontwikkelen.

Een goed voorbeeld is de open-source gemeenschap waarbij iedereen die wil luisteren op de hoogte word gebracht van het gestarte onderzoek via de gebruikelijke kanalen en personen die een uitermate interesse tonen kunnen zich onafhankelijk van hun voorkennis zich tussen de rangen vervoegen en hun rol in een zeer enthousiaste en leerrijke gemeenschap vervullen. Omdat de open-source gemeenschap geen eisen stelt qua diploma, titel of voorkennis voorziet het een zeer lage instap drempel voor iedereen om mee te doen met wetenschap en wiskunde aan het hart van deze gemeenschap.

Velen zouden betwisten dat het een goede zaak is om eenieder toe te laten terwijl dit zeker wel is, aangezien wanneer iemand deze gemeenschap binnentreedt beschikt deze reeds over hetzelfde enthousiasme dat deze hele gemeenschap drijft waardoor de wil om te leren zeer groot is en het leren dus zeker niet uitblijft. En in het begin zal de bijdrage van deze aspirant inderdaad miniem zijn maar zal worden geapprecieerd desondanks.

Anderen bekritiseren de open-source gemeenschap omdat deze alleen leid tot slechte producten die niemand uiteindelijk wil. Voor die personen kan ik slechts zeggen: kijk eens rond en vraag u zelf eens af hoeveel producten die je momenteel in gebruik neemt zijn geheel of gedeeltelijk ontstaan uit de open-source gemeenschap?

Zoals altijd apprecieer ik opbouwende kritiek wees dus niet bescheiden en laat deze gerust hier onderaan achter

Voor een mooier web

Iedere webdesigner/-developer kent de pijn van verouderde browsers en de meegebrachte incompatibiliteit. Bij elk nieuw project moet je er rekening mee houden, elke klant houdt er rekening mee en de optimalisatie voor deze browsers en hun incompatibiliteit neemt meer tijd in beslag dan jij er mogelijk wilt aan besteden.

Er zijn verschillende initiatieven de revue gepasseerd maar we hebben uiteindelijk toch moeten concluderen dat er geen eenduidige wijze is waarop men moet omspringen met deze incompatibiliteit. Ervaren ontwerpers en ontwikkelaars weten één ding zeker je website kan niet, zal niet en moet niet er hetzelfde uitzien in elke verschillende browser omdat elke browser nu eenmaal een andere manier van weergave toepast waardoor jouw lettertype Arial, Verdana of Helvetica in Firefox er anders zal uitzien in Opera en Internet Explorer.

Deze hele achterwaartse compatibiliteit heeft nog een groter nadeel dan alleen de tijdsduur die zij inneemt nl. kostprijs. Die niet elke klant wenst te betalen, zeker niet als kan worden aangetoond dat zijn doelpubliek hypermoderne browsers gebruiken of één bepaalde browser bijv. add-ons distributie voor de Firefox browser, widget distributie voor de iPhone.

Maar ook al kan je aantonen dat jouw doelpubliek hypermoderne browsers gebruikt dan is de kans reëel dat er wel af en toe een IE6 browser op bezoek komt tot gevolg dat zij een gebroken website voorgeschoteld krijgen, wat de gebruiksvriendelijkheid van je website doet zakken tot een dieptepunt.

Dean Edward presenteert wat mogelijk een oplossing kan vormen nl. een universeel css bestand dat jouw website voor IE6 gebruikers op een waardige manier vormgeeft, zonder al de fancy afbeeldingen en langs jouw kant geen inspanning vereist. Deze oplossing neemt één stelling aan nl. gebruikers bezoeken jouw website voor de inhoud (niet zijn vormgeving). Deze methode kan dus niet worden toegepast op bijv. een portfolio van een kunst-ontwerper.

Het volledige artikel kan je terugvinden op forabeautifulweb. Edward somt ook alternatieven op die werden toegepast in het verleden waaruit wij hebben kunnen concluderen dat er geen eenduidige wijze is waarop er kan worden omgegaan met verouderde browsers en de incompatibiliteit die zij meebrengen.

Hoe spring jij om met IE6 en verouderde browsers in het algemeen?

Lazy-Loaded Thumbnails

Het origineel idee kan worden teruggeschreven aan MrBurly en gaat als volgt:

Stel in een deel van je applicatie gebruik je thumbnails en dus schrijft jouw applicatie:

/images/thumbs/an-image-thumb.jpg

Stel nu even dat deze afbeelding nog niet bestaat? Iedereen weet dat met wat .htaccess magie kan je url’s herschrijven zoals dit gewoonlijk gedaan word bij het Zend framework. Dus ook deze url zal worden herschreven en word dus doorgegeven aan het Zend framework waarna jij via de controller images met een actie thumbs deze informatie kan opvragen en de benodigde thumbnail kan maken. Je kan deze functionaliteit ook verder uitbreiden naar bijv. iets als:

/images/thumbs/an-image-thumb-100×100.jpg

Hiermee zou het mogelijk worden om thumbnails te maken op een specifieke grootte. Dit heeft wel één groot nadeel natuurlijk, de eerste ongelukkige eindgebruiker zal een aanzienlijke tijd moeten wachten voordat alle thumbnails gemaakt zijn. Alle eindgebruikers daarna zullen zelfs niet via Zend moeten passeren om hun afbeeldingen te laden omdat het pad nu wel geldt.

Het volledige artikel dat eigenlijk gaat over een implementatie van het Delegation Pattern kan je terugvinden op de website van mrburly.