http://blog.joggink.com is the new address (and in the future this blog will disappear and replaced with the new blog).

Don’t forget to update your rss readers, the new feed can be found here:

http://feeds.feedburner.com/bloggink

Instapaper is een superhandige service, voorzien van een nuttige iphone app, een soort van read-it-later service. Het enige grote nadeel voor mij is de bookmarks link. Zelf worden mijn bookmarks niet weergegeven omdat ik delicious gebruik als bookmark service en bijgevolg ook de delicious addon heb ipv de standaard firefox bookmarks.

Daarom besloot ik om eens met jetpack een add-to-instapaper functie te maken. De reden waarom ik voor jetpack koos is omdat het in javascript geschreven wordt én dat jquery gebruikt kan worden.

Meer info over de jetpack plugin:
http://labs.joggink.be/jetpack/instapaper/

Ik haat smaldenkers… Als je een simpele layout niet om kan zetten naar semantische code én correcte css in 47 minuten, dan ben je inderdaad een loser en geef je het beter op, maw zoek ander werk. Tables gebruiken is nog maar eens een bewijs dat sommige mensen liever lui dan moe zijn. Het web evolueert iedere dag, en van de honderden zaken die mensen ontwikkelen zit er dagelijks mss 1 tussen die iets kan betekenen omdat er:

1. over nagedacht is
2. de correcte technologie gebruikt is om de doelstelling te bereiken
3. het geheel semantisch correct is

De reden waarom ik maar blijf zagen over semantiek is omdat vele mensen het verschil niet snappen tussen xhtml strict / transitional en semantische webpagina’s. Het is niet omdat je webpagina valideert op w3c dat hij semantisch correct is.  <div id=”pageTitle”><span class=”vet”>dit is de titel</span></div> zal vanzelfsprekend valideren, terwijl het beter zou zijn om <div id=”header”><h1>dit is de titel</h1></div> te gebruiken. Niet enkel naar SEO toe, maar ook naar screenreaders, slechtzienden, …

Anyway, om af te sluiten nog 1 link:

http://shouldiusetablesforlayout.com/

IE 6 zuigt big time, geen png transparency, slechte css implementatie, … Ik weiger dan ook resoluut om nog te ontwikkelen voor deze browser. Wetende dat deze browser voor het eerst op de markt kwam op 27 augustus 2001 vind ik het niet meer dan logisch dat gebruikers hun software updaten. Jammer genoeg is het heden ten dage de omgekeerde wereld en verwachten IE6 gebruikers dat wij hun browser nog supporten. No shit sherlock maar ik heb nieuws voor je, er is namelijk een nieuwe versie gelanceerd op 27 juli 2005 en die heeft het nummertje 7 meegekregen en heeft volgende fancy features:

• Tabbed browsing: wat een revelatie! Meerdere sites, in 1 browser! Wicked!
• Streamlined interface: hier zaten we echt op te wachten… Beauty patches, same shit different look
• advanced printing: adjust margins, remove headers en footers…
• rss feeds: welcome to the new era!

Anyway, zelfs als je nog van plan bent om de 7 te installeren, haast u vooral niet, want de acht komt eraan, die kan dan mss binnen een jaar of 8 geïnstalleerd worden, niet?

De achtste telg beloofde de eerste te worden in lange rij die deed wat er moest gebeuren, namelijk pagina’s valide weergeven… En again, they fucked it up…

Related:

• IE6 can officially blow me

ColorZilla

Geavanceerde Eyedropper, ColorPicker, paginazoomer, copy past mogelijkheid van rgb/hex codes, …

Firebug

Met firebug kan je super-easy elementen inspecteren, css on the fly wijzigen om te zien wat het resultaat is, door de DOM tree navigeren, ajax requests bekijken, … Een must have voor iedere zelfrespecterende developer.

Firecookie

Uitbreiding op firebug waarmee je snel de cookies kan bekijken die op de huidige pagina actief zijn.

Inline Code Finder

Uitbreiding op firebug die inline css, inline javascript en javascript links opspoort en deze visueel toont.

YSlow

Uitbreiding op firebug die een uitgebreide analyse weergeeft over de snelheid van je webpagina

Firefox Accessibility Extension

Toont mogelijke knelpunten voor mensen met een visuele handicap

Screengrab!

Snel en gemakkelijk screenshots nemen van webpagina’s of een selectie van de webpagina

Web Developer

Superhandig om snel css / javascript uit te schakelen, inzoomen op webpagina’s, outlines te tonene, te valideren, … Een must have!

Venkman

Venkman is de codename voor Mozilla’s JavaScript Debugger. Superhandige console om breakpoints te zetten en geavanceerder fouten op te sporen.

• Alle ergernissen hieronder beschreven zijn mijn personlijke ergernissen en niet die van mijn werkgever.
• Ik viseer niemand, mensen die zich toch zouden aangesproken voelen beschikken blijkbaar over voldoende zelfkennis.
• Ik vind mezelf verre van perfect of alwetend, maar met de doorheen de jaren verworven kennis tracht ik toch het beste van mezelf te geven bij het realiseren van projecten

In mijn vorige post had ik het redelijk beknopt over de frontend ergernissen, maar laat ons vooral het geblunder van sommige backend developers niet vergeten. Frontend en backend zijn een tandem, 2 mensen die perfect moeten samenwerken en weten wat er waar moet gebeuren. Een site mag nog überclean gelayout zijn, met kraaknette w3 valide xhtml / css geschreven zijn, fancy javascript effectjes bevatten de grote dooddoener blijft SNELHEID.

Snelheid is dikwijls al de grootste fout bij vele developers. Soms werkt hun site traag, en meestal wordt de oorzaak geweten aan de “trage webserver”, bijgevolg worden klanten de kosten ingejaagd om zwaar te investeren in een energievretende killerserver die pagina’s serveert aan de luttele 5 bezoekers per dag.

Er kunnen verschillende oorzaken zijn, soms 1, mss 2, en soms is het helemaal in orde gedaan en zijn er 1001 zaken die van een slick site een lomp geheel maken.

Laat ons beginnen bij de basis, zijnde de database… Laat ons even de manual ter hand nemen. (Backend developers die nu mijn site verlaten, er bestaan wel degelijk manuals, en néén, deze zijn niet geschreven voor uw buurvrouw die weleens een stap op het wereldwijde web wil wagen, manuals zijn geschreven voor iedereen, en wél in het bijzonder voor diegene die zich goed genoeg achten om het zonder te kunnen.) Een goede database is genormaliseerd, beschikt indien nodig over de juiste relaties / tussentabellen en heeft vooral velden die geoptimaliseerd zijn voor de inhoud. Ok, je kan al je data opslaan in varchars, text of BLOB velden, dan heb je “plaats genoeg”, maar dan verlies je het doel van je database uit het oog.

De juiste velden gebruik je om:

• de juiste data te kunnen uitlezen en op QUERY niveau te kunnen filteren (datums selecteren op MONTH, etc…)
• de juiste data te kunnen inserten en laten valideren op DATABASE niveau

Als voorgaande punten al goed zitten, petje af, een bank vooruit en een kus van de juf! Op naar de volgende vaak voorkomen fout, zijnde te véél queries. Data selecteren is 1 ding, maar data filteren, grouperen en sorteren gebeurt op database niveau. Zaken als DISTINCT, GROUP BY, ORDER BY, ASC, DESC, JOIN, INNER JOIN, OUTER JOIN, … zijn geen fancy sql commando’s. Maar al te vaak wordt data uitgelezen, in een array gepompt om die op zijn beurt te sorteren / filteren, door te loopen en per loop nogmaals een query afvuren, performantie troef. Mensen die dit doen zouden moeten verplicht worden om enkel genoeg benzine in hun  tank te doen tot aan het volgende tankstation, zodat ze mss het concept snappen. De pipeline tussen de webserver en database server is klein, zeer klein. Zorg er dus voor dat je niet méér dan de benodigde data terugkrijgt. Net zoals schoenen kopen weet je ook welke maat je nodig hebt (of mss 2 maten), welke kleur, mannen of vrouwenschoenen, etc… De verkoper alle schoenen laten aanrukken én ze vervolgens 1 voor 1 passen zou een beetje overhead zijn, niet? (voor sommige vrouwelijke lezers, ik veroordeel je niet als je de voorgaande stelling niet snapt). Voor diegene die Roger van Dobbit magazine kennen, vergeet zijn wekelijkse stelling. “Wat je zelf doet, doe je beter” klopt voor geen vliegende meter als het op databases aankomt.

Voor de betweters die bovenstaande stellingen zouden benchmarken, ga uw gang. Een vertraging van 0,2 ms is niet veel voor 1 record, maar wat bij 10.000 records?

Het programmeren op zich kan nog op 1001 vlakken fout gaan, teveel om op te noemen. Misschien volgende zaken toch in het achterhoofd houden:

• Object Oriented programmeren is vandaag de dag HOT, het maakte zijn opmars begin de jaren 90 maar het principe bestaat al van in de jaren 60. Het is niet omdat je volgens OO programmeert dat je een kickass developer bent. Bekijk OO design patterns, snap alle principen (inheritence, abstraction, encapsulation, polymorphism, decoupling)…
• Frameworks zijn geschreven om het leven te vergemakkelijken, gebruik ze dan ook indien mogelijk.

wordt vervolgd

Pars pro toto is een stijlfiguur waarbij de auteur een gedeelte van een object noemt wanneer hij het hele object bedoelt. Hij gebruikt dus een deel (pars) terwijl hij het geheel (toto, ablatief van totum = geheel) bedoelt: deel voor geheel (pars pro toto).

bron: http://nl.wikipedia.org/wiki/Pars_pro_toto

Met andere woorden, 1 deel beschrijft het geheel, of om het door te trekken naar javascript, 1 script beschrijft de script library. U denkt, niets nieuws onder de zon, en misschien hebt u wel een punt, maar tot op heden ben ik dit nog niet echt tegengekomen.

Als we grote javascript libraries als mootools bekijken, dan is er een “download” pagina waar u alle benodigde classes in 1 grote javascript file, netjes gepacked kunt downloaden. Ideaal, want de browser caching zorgt er voor dat deze file niet nodeloos gedownload wordt ieder bezoek.

Maar… als we nu eens uitgaan van een gigantisch grote library met extreem veel utilities, dan heb je 1 grote js file die moet ingeladen worden. We kunnen er vanuit gaan dat 99% van de mensen wel een snelle internetverbinding hebben en hier weinig tot niets van merken, maar het is iets complexer dan dat.

Diegene die geregeld mijn blog volg(d)en weten dat ik een eigen javascript library ben beginnen ontwikkelen, namelijk de joink library. Deze biedt geen enkele meerwaarde dan de bestaande libraries behalve het feit dat ik ze zelf geschreven heb en er bijgevolg snel mee kan ontwikkelen. Nu wil het toeval dat we deze library bij ons ‘op den bureau’ ook geimplementeerd hebben en er geregeld ‘utilities’ geschreven worden die iets van “dom-magie” uitvoeren.

Waar het grotendeels op neerkomt is dat de joink library een reeks core files heeft en een heleboel utilities (denken we maar aan drilldown functionaliteit, autosuggest, etc…). Om het even in een logische boom te gieten:

Wat onmiddellijk opvalt zijn al de utilities, nu nog niet zo héél veel, maar bij grote projecten waar redelijk wat utilities gebruikt worden om het geheel wat op te schonen is het een hel om een mooi overzicht te houden van wat waar geinclude moet worden, etc…

Vandaar het fantastische idee om per joink.utils.xxx.js file aan te geven welke files er nodig zijn omdat de boel zou werken, zodoende kan ik deze dan on the fly inladen. Om de boel nóg gemakkelijker te maken wilde ik slechts 1 file (de joink.js core file) includen en deze alle benodigde files te laten includen wanneer deze nodig zijn.

Als ik dus bijvoorbeeld een joink.fx object aanmaak moet mijn joink.parsprototo de joink.fx.js library inladen én bijgevolg ook de joink.bezier.js file die nodig is om de animatiecurves te genereren…

Op onderstaande link is een proof of concept uitgewerkt (redelijk vlug geschreven, dus niet echt op de netheid van de code letten aub :p). Er zitten nog wat plooien in, maar deze worden zeker nog gladgestreken.

Proof of concept: http://labs.joggink.be/proof-of-concept/parse-pro-toto/

Bijgevolg werd movable type gemoved naar de schroothoop, een nieuw subdomain ontsproot vanuit het zwarte movable gat en ziehier, een stralende zonneschijn, helderblauwe hemel en parelwitte stranden, oftwel wordpress op een subdomain.

Nogmaals, excuses en laat het niet aan uw hart komen.

• Alle ergernissen hieronder beschreven zijn mijn personlijke ergernissen en niet die van mijn werkgever.
• Ik viseer niemand, mensen die zich toch zouden aangesproken voelen beschikken blijkbaar over voldoende zelfkennis.

Bij het rondsurfen op het overbevolkte wereldwijde web én tijdens het ontwikkelen van webapps erger ik me dood aan allerhande zaken. Ook even vermelden dat ik mezelf niet aanzie als alwetende guru, verre van, maar ik probeer wel om alle verworven kennis te verwerken en solide semantische producten af te leveren die browseronafhankelijk werken. Webontwikkeling bekijk ik met hetzelfde kritische oog als wanneer ik terugkijk naar jeugdfoto’s van begin de jaren negentig. Toen waren bepaalde kleuren en kledij kenmerken hip, cool en trendy, maar de dag van vandaag spuiten ze je plat en sluiten ze je met een dwangbuis op in de eerste de beste psychiatrische instelling. Als we dit zouden doortrekken op de webontwikkeling in de jaren negentig denken we maar al te graag aan spacey backgrounds, tabledesigns, comic sans ms en andere rariteiten. Heden ten dage zijn er nog altijd hobbyisten en so-called-professionals die tabledesign gebruiken… Deze mensen hierop wijzen is als een hond leren fietsen: onbegonnen werk en een muur vol onbegrip waarom ze het maar niet willen snappen. However, soms is er héél toevallig een witte raaf die het licht ziet en er zich toch eens in wil verdiepen in dat “table-less design”. Dit resulteert meestal in een overdreven zware vorm van schrijnende divitis. Laat ons duidelijk zijn, het is niet omdat je een <div> tag gebruikt dat je semantische websites maakt, verre van. Ulitis is soms ook aan de orde, want unordered lists zijn “the way to go” blijkbaar. Divs en ul elementen zijn een goed begin, maar het begrip “semantische websites” is iets ruimer dan divs en ul’s… Wat is er verkeerd aan hx tags? strong? em? p?

Ontwikkelaars die al iets langer bezig zijn in de webwereld komen weleens in aanraking met css, javascript en “hoe heette het ook alweer?”, juist ja AJAX! Ajax is blijkbaar hét trendwoord, want ajax kan vanalles zonder page refresh. Even enkele opmerkingen omtrent ajax:

• Ajax is niet gemaakt om frames te vervangen en hele pagina’s content in te laden
• Ajax is niet meer of minder dan een httprequest in javascript (dus een javascript animatie is geen ajax, laat ons daarover al duidelijk zijn)
• Ajax is geen nieuwe übercoole technologie, want laat ons eerlijk zijn, de manier waarop we data transporteren over het internet is nog altijd het http protocol.

Javascript kan een meerwaarde bieden als het correct gebruikt wordt, lees ‘unobtrusive werkt’. Unobwat? Unobtrusive betekent dat je site perfect werkt met of zonder javascript. Javascript doet zijn magische werk zonder dat de gebruiker het doorheeft hoe alles werkt achter de schermen.

So far over de frontend ergernissen die ik heden ten dage ervaar, binnenkort meer over backend irritaties, zijnde crappy serverside code en niet genormaliseerde databases die je systeem plattrekken.