Berichten over ‘hersenspinsels’

Ik zat in bad en dacht na.
Goed – Beter – Best herinnerde ik mij nog uit het lager…
In die volgorde hadden wij het geleerd.  En best was wel degelijk de overtreffende trap van beter.
Maar wat als een beste oplossing niet goed is?
Stel: je hebt de keuze uit een slechte oplossing en een slechtere oplossing.
Dan is in dat geval de minst slechte oplossing de beste.
Maar dat wil nog niet zeggen dat die oplossing goed is, maar wel beter dan de slechtste…

Raar hé 😀

opstaan 7 uur: Ben nog moe, niet wakker. zuur.
8 uur: ontbijten dan. Geen zin, geen honger, snel een boterham.
9 uur: Eindelijk boven, beginnen leren, ik heb het moeten beloven.
9 uur en 1: *pling* daar begint het al: nieuwe mail.
9 uur 15: een nieuwe mac (en ander nieuws) dat had ik nog niet gezien.
12 uur: etenstijd. Niks geleerd, heb een beetje spijt.
1 uur: belgerinkel, ga jij mee naar de winkel?

2 uur: terug boven, snel wat leren, ik heb het moeten beloven.
2 uur 5: Hé, wat is dat met m’n schijf?
3 uur: schijf macheert. Ik ben een pro… maar heb nog niks geleerd.
4 uur: Tijd voor een koek. Motivatie om te leren raakt stilaan zoek.
4 uur 40: ’t zit niet mee. Hoe zit het met m’n kennis van Java of PHP?
6u: Avondmaal: M’n nieuw programmaatje werkt. Ik ben geniaal.

7u: Alweer boven, om écht te leren, ik heb het moeten beloven.
8u: Tijd voor TerZake. Ik moet toch van iets op de hoogte raken?
9u: Snel een spel. Max 10 minuutjes en dan begin ik écht wel.
12:30: Dat ging snel voorbij! Er moet echt meer tijd zijn voor mij.
12:31: Snel die cursus open en wat leren. Voor nacht en dag weer keren.
2u: Tranendal. Ik moet beter kunnen, dat weet iedereen toch al?
3u: Oogjes dicht. Wacht, ik schrijf nog even een gedicht.
3:20: Tijd dat ik in slaap val en bedenk dat morgen… net hetzelfde wezen zal.

Deze zondag, ergens in de late namiddag, zat ik in de bus op weg naar huis. M’n laatste dag als leider zat er bijna op en bij de eerste zonnestralen (het was een regenachtige dag geweest) die te voorschijn kwamen, keek ik terug naar wat ik al die jaren had beleefd.

Die eerste jaren als kapoen bijvoorbeeld: voor de eerste keer op weekend, voor de eerste keer op kamp, samen spelletjes spelen, leren samenwerken om iets  te bereiken. Het was allemaal echt geweldig! We hadden nog veel fantasie en waren er zeker van dat er Orks in de bossen schuilden. Hoe kon het ook anders, met een weekendthema als Lord of the Rings en leiding die alles in een heerlijk kleedje gestoken had?

Of bij de jonggivers, waar je al in tenten mocht slapen, zelf vuur leerde maken en op tweedaagse mocht. Je mocht niet liften, maar stiekem deden we het toch. Het was spannend, leuk en met weemoed dacht ik terug aan de verre staptochten die we maakten, en aan de adembenemende vergezichten die verscholen lagen tussen een paar bossen en dan stap voor stap tevoorschijn kwamen. Zelfs als 14-jarige maakt dat je even stil.
Of het 24-uren spel waarbij je zowel zonsop- als ondergang kon zien of slierten mist die over de velden zweefden en de volledige omgeving nét iets meer sprookjesachtig maakten.

Of die tijd toen ik bij de Jins zat, waar we zelf geld moesten verdienen om op buitenlands kamp te kunnen gaan dat we dan ook semi-zelf in elkaar mochten steken. Gelukkig met leiding die dan een oogje in ’t zeil houdt.

Of het eerste jaar zelf in leiding staan, zelf verantwoordelijkheid nemen. Beseffen dat leiding méér is dan zondagmiddag van 2 tot 5. Groepsraden, leidingsweekends, vzw-vergaderingen en nog zoveel andere dingen waarvan ik als lid niet eens wist dat ze bestonden. Maar ik deed het graag. Ik heb veel geleerd in die 5 jaar dat ik in leiding stond. Ik heb opgekeken naar mijn groepsleiding die voor veel problemen een perfecte oplossing in petto had.
Ik heb ook groepsleiding gehad waarbij ik het vaak niet eens was met de beslissingen die ze namen. Maar ook dat hoort er bij en ook daarvan heb ik veel geleerd. Ik heb het geluk gehad om altijd met toffe mensen in een tak te staan en ik ben ze daar bijzonder dankbaar voor. Zeker in m’n eerste jaar heb ik gigantisch veel geleerd van m’n medeleiding. Nadien was ik blij dat ik mijn kennis ook kon doorgeven, ook al was dat niet zo veel, ik hoop dat ze er iets aan gehad hebben.

Dit alles is maar een fractie van wat er tijdens de busrit door m’n hoofd ging, nog zoveel meer dingen die ik heb meegemaakt zou ik hier kunnen neerpennen. Uiteindelijk stopte de bus vlak voor het scoutslokaal en schoot ik wakker. Ik stapte uit de bus, zwaaide nog even naar m’n vertrekkende leden en babbelde nog even na met de leiding. Niet veel later vertrok ik naar huis. Voor de allerlaatste keer…

…en dat is informatica ook niet.

Nog niet zo lang geleden las ik  een opiniestuk waarin de schrijver het gebruik van de Rorschachtest als diagnostisch instrument in professionele omgevingen hekelde.
Daaruit bleek dat mensen onvoorspelbaar zijn en dat we eigenlijk nog altijd niet met zekerheid kunnen zeggen hoe iemand zal reageren in een bepaalde situatie.
Psychologie is dus geen exacte wetenschap.

Wiskunde, en bij uitbreiding informatica, horen dat wel te zijn denk ik dan. Maar is dat wel zo?

Als ik één optel bij één dan komt iedereen, waar ook ter wereld, uit bij twee. Omdat er ooit is afgesproken dat 1 + 1 gelijk is aan 2.

Mocht ik die formule in een computerprogramma zetten, dan zal ik ook altijd 2 als uitkomst krijgen.

Probeer onderstaande Java-code maar eens uit te voeren. Wedden dat je 2 als resultaat krijgt?

package som;

public class Main {

    public static void main(String[] args) {
        telOp();
    }

    public static void telOp(){

        int antwoord = 1 + 1;

        System.out.println(antwoord);
    }

}

Uiteraard, denk je, het hoort twee als antwoord te geven. Dat is toch logisch?

En daar heb je gelijk in. Alleen, wanneer een programma behoorlijk groot begint te worden en bestaat uit ongelooflijk veel lijnen code, dan zal er -altijd- ergens een fout inzitten die ofwel nog niet ontdekt is ofwel zo banaal is dat men de moeite niet doet om de fout er uit te halen.

Op zich is dat niet erg natuurlijk, het programma zal waarschijnlijk wel doen wat het moet doen en in het leeuwendeel van de gevallen werkt alles zoals het hoort.

En zo is het net bij de mens. Hoeveel lijnen code zouden er nodig zijn om het menselijk brein in een programma te steken? Gigantisch veel lijkt me.
Een programma van die omvang zal ongetwijfeld fouten bevatten.
Zelfs als het door de beste programmeurs die je op aarde kan vinden in elkaar gestoken wordt.
Zelfs als verschillende mensen het zouden nakijken op fouten.

Nochtans, het is allemaal code. Alleen maar ‘ja’ of ‘nee’. Dezelfde code die verantwoordelijk is voor onze 1 + 1 = 2.

Het programma dat het menselijk brein moet simuleren zal daardoor even “exact” zijn als het echte menselijke brein. Niet helemaal exact dus. Net zoals psychologie en dus ook net zoals… informatica.

Synchroniseren. Hoe moeilijk kan het zijn? Je neemt potlood en papier en tekent snel wat schemaatjes met een aantal scenario’s die zich mogelijk kunnen voordoen bij het synchroniseren. Deze blogpost is het verhaal waarin ik op zoek ga naar de ideale manier waarop verschillende mobiele devices steeds over dezelfde informatie (vakken) beschikken én die informatie kunnen aanpassen. Simpel, toch?

1. Data downloaden en gewoon alles overschrijven.
   Toegegeven, dit is nogal drastisch. Maar hé, het werkt. We vergeten gemakkelijkheidshalve dan wel dat ALLE data downloaden zelden nodig is, laat staan alles overschrijven…
   Eigenlijk had deze eerste stap meer als doel vertrouwd te raken met de API van de rest-server. Data versleuteld downloaden, aanmelden met Digest access authentication, gegevens versturen naar de rest-server etc.

   
   

   Start

   
   Your browser does not support the canvas element.
   

   Stap 1: Data downloaden en gewoon alles overschrijven.

2. Kijk welke vakken niet online staan (op basis van ID) en download enkel die vakken.
   Stap twee, we voegen basislogica toe aan het downloadproces.
   We downloaden niet meer klakkeloos alle vakken, maar enkel de vakken die we nog niet hebben. Om dat te kunnen doen, maken we twee lijstjes met alle vak-ID’s online en alle vak-ID’s offline. Daarna vergelijken we beide lijstjes en weten we welk vak ontbreekt en waar het ontbreekt.
   In het geval van het prentje hieronder ontbreekt online het vak met ID 125. Dat vak uploaden we dus naar de online database zodat we daar ook vak 125 hebben.
   

   Stap 2: Vergelijk ID’s van vakken online met vakken offline

3. Kijk welke vakken offline staan, kijk welke vakken online staan en synchroniseer deze.
   Oeps! Probleem. Een ID-nummer is immers niet representatief voor een vak. Als ik offline een nieuw vak aanmaak dan zal dat nieuwe vak een nieuw ID-nummer krijgen. De kans is groot dat er ondertussen online ook een vak is aangemaakt met datzelfde ID. Hoewel het vak met ID-nummer 195 dus zowel offline als online aanwezig is, gaat het wel degelijk over een ander vak. Afgaan op ID-nummers gaat dus niet. Een vak-ID is dus enkel representatief voor één vak binnen dezelfde database. Als we met verschillende databases werken, in dit geval online en offline, dan kan een vak-ID twee keer voorkomen en toch naar een ander vak verwijzen.Het probleem ligt bij de automatische nummering in de database. Nieuwe inhoud krijgt een nummer mee dat net 1 eenheid groter is dan de vorige inzending. Als een device geen verbinding heeft met het internet en de laatste inzending 124 was dan zal de volgende inzending 125 zijn. Ook als er ondertussen door andere mensen 30 nieuwe vakken ingediend zijn en het eigenlijke ID-nummer dus 155 had moeten zijn.
   

   ID is hetzelfde, titel is anders

   Een mogelijk oplossing bestaat eruit de data zelf te gaan vergelijken. Omdat het over (potentieel) gevoelige data gaat, leek het mij veiliger om niet de data zelf maar de md5-hashes van de data te gaan vergelijken. Dat werkte.
   Als we met verschillende data zitten en het ID-nummer is hetzelfde, nemen we de meest recente wijziging.

   

   Vergelijken van vaktitels dmv md5-hashes

   Oh ja?
   Want als we zowel vak 125 online als het vak 125 offline willen behouden, dan zal dat niet gaan. We zouden 1 van beide immers overschrijven met het vak dat het laatst werd aangemaakt.

   Of stel: Jan Janssens synchroniseert in februari zijn data en vertrekt een maand op vakantie. In maart vinden er verschillende grote wijzigingen plaats in de online database. In april keert Jan Janssens terug, kan niet synchroniseren, maar maakt toch een aanpassing aan de data en wil dan zijn veranderingen online opslaan.

   Probleem! Hoewel de data van Jan Janssens wel over de recentste data beschikt, is het zeker niet zijn data die we online willen hebben.

   Data samenvoegen (mergen) met de reeds bestaande data, is door de aard van de data niet mogelijk. Oeps.

   Volgende idee: we bewaren beide vakken, wetende dat dat niet ideaal is.

4. Bewaar beide vakken.
   Bewaar beide vakken. Ok. Maar hoe? Ze hebben hetzelfde ID. Moeten we dan nog een tabel aanmaken die het online ID koppelt aan het offline ID? Moeten we het vak-ID aanpassen? Maar hoe? En wat wanneer er al een vak bestaat met dat nieuwe ID? Gaan we bij elke synchronisatie dan op zoek gaan naar alle vrije ID’s en dat vak dan dat nieuwe ID geven? Op die manier zou het kunnen dat een vak tijdens zijn bestaan verschillende keren van ID verandert. Ook niet echt ideaal denk ik dan.

5. Hou een logboek bij met veranderingen.
   Vanaf hier is het pure improvisatie, louter gebaseerd op een denkoefening en (nog) niet geprogrammeerd. Informatie onder voorbehoud dus.In onze database maken we een nieuwe tabel aan waarin we alle veranderingen opslaan.
   Als er bij die veranderingen bijvoorbeeld een vak aangemaakt is en online heeft er nooit zo’n actie plaatsgevonden dan weten we, ongeacht het vak-ID, dat er online een nieuw vak aangemaakt moet worden. Omgekeerd werkt dat ook uiteraard, als er online een vak is verwijderd en dat vak is nog wel offline aanwezig dan kunnen we dat vak verwijderen. Hoe weten we nu welk vak verwijderd moet worden als we vak-ID’s niet mogen vertrouwen?
   We slaan bij elke verandering een md5-hash van de data op, we vergelijken dan de md5-hash van die online data met de md5-hash van onze data offline.Zo’n tabel met alle aanpassingen wordt uiteraard in no-time gigantisch groot. We slaan immers alle data dubbel op.
   Op zich geen probleem, maar we hoeven die data niet voor eeuwig te bewaren.

6. Vergeet veranderingen
   Offline is dat redelijk eenvoudig. Als het device verbinding gemaakt heeft met de server en alle gegevens gesynchroniseerd zijn, dan kan het volledige lokale logboek met de veranderingen verwijderd worden. Online is het iets ingewikkelder. Omdat we niet weten hoeveel devices er zijn en sommige devices maar 2 of 3 keer synchroniseren en daarna nooit meer, kunnen we onmogelijk alle veranderingen blijven bijhouden.

Deze manier van data synchroniseren is het resultaat van een persoonlijke denkoefening en dus verre van perfect. Moesten er slimme mensen op de wereld zijn die voor dit probleem een betere oplossing hebben,  lees ik hun oplossing graag in de commentaren hieronder.

Note: In dit voorbeeld gebruik ik als voorbeeld md5 om data te encrypteren. Ik ben mij er van bewust dat er andere en betere manieren bestaan om data one-way te encrypteren. Mocht je dus echt gevoelige data willen opslaan doe je er goed aan jezelf hierover eerst te informeren. ;-)