Blog

  • Stryd hoogte nauwkeurigheid getest

    Stryd hoogte nauwkeurigheid getest

    Belangrijkste conclusie
    Dit artikel test de nauwkeurigheid van de hoogtemeters van Stryd, niet de nauwkeurigheid van Stryd voor tempo, afstand of vermogen. Bij herhaalde trapbeklimmingen op de Kwintelooijen bleek Stryd, vergeleken met AHN4-hoogtedata als referentie, de totale hoogtestijging te laag in te schatten. In de test van april registreerde de activiteit met de Stryd-pod 1.641 m tegenover 2.181,82 m volgens AHN4, dus ongeveer 25% te laag.

    Hoe betrouwbaar zijn de hoogtegegevens?

    Om specifiek wat hoogtemeters te kunnen maken, ben ik onder andere een aantal keer bij de trap in het natuurgebied Kwintelooijen geweest. Het mooie hieraan is dat het recht omhoog, en weer recht omlaag gaat. Dat maakt het makkelijk om te gebruiken als meetpunt voor de betrouwbaarheid van de hoogtemeters: je neemt simpelweg het verschil tussen het hoogste en het laagste punt.

    Ik draag een Garmin Fenix 8 (43 mm) amoled horloge en de Stryd Duo footpods als combinatie waarmee ik opneem. Activiteiten laat ik vervolgens synchroniseren naar Strava en Stryd. Als ik de hoogte data van Garmin, Strava en Stryd in een tabel zet dan krijg je het volgende.

    15-02-202513-04-2025
    Garmin fenix 8 softwareVersie 12.38Versie 13.35
    Aantal keer de trap30 x59 x
    Stijging volgens Garmin1.049 meter2.071 meter
    Stijging volgens Strava1.049 meter2.071 meter
    Stijging volgens Stryd870 meter1.823 meter

    Oftewel, volgens Stryd heb ik helemaal niet de verticale afstand gehaald die ik dacht te halen op basis van de gps! Wie heeft er nu gelijk?

    Gelukkig hebben we in Nederland een erg nauwkeurig DSM (Digital Surface Model, dit is de maaiveld hoogte) in de vorm van AHN (Actueel Hoogtebestand Nederland). Als ik deze trap hierop plot, met behulp van AHN4 dan krijg ik het volgende. Zie deze link https://viewer.ahn.nl/AHN4/DTM/…. Op dit moment wordt AHN versie 5 gemaakt, die is voor Kwintelooijen nog niet beschikbaar dus AHN4 is de meest recente en meest nauwkeurige hoogtedata die beschikbaar is.

    AHN hoogte data

    Hieruit blijkt een hoogteverschil van 50,88 – 13,90 = 36,98 meter. Met deze data kunnen we de tabel verder aanvullen.

    15-02-202513-04-2025
    Garmin fenix 8 softwareVersie 12.38Versie 13.35
    Aantal keer de trap30 x59 x
    Stijging volgens Garmin1.049 meter2.071 meter
    Stijging volgens Strava1.049 meter2.071 meter
    Stijging volgens Stryd870 meter1.823 meter
    Stijging volgens AHN41.109,4 meter2.181,82 meter
    Afwijking Garmin t.o.v. AHN4-60,4 meter -110,82 meter
    Afwijking Stryd t.o.v. AHN4-239,4 meter-358,82 meter
    Afwijking Stryd t.o.v. Garmin-179 meter-248 meter
    Verhouding afwijking Stryd t.o.v. afwijking Garmin3,964 x3,238 x


    Conclusie: Stryd wijkt 3 tot 4 keer meer af van de werkelijkheid voor hoogtemeters dan de gps data van Garmin in deze 2 gevallen!

    Het is mij eerlijk gezegd niet duidelijk of Stryd zich alleen op gps data baseert, waar ze een onjuist correctie algoritme overheen leggen, of dat ze daadwerkelijk de pods gebruiken om hoogtedata te berekenen. Wel goed om te vermelden is dat de horizontale afstand van Garmin, Strava en Stryd wel bijna identiek is.

    15-02-202513-04-2025
    Garmin fenix 8 softwareVersie 12.38Versie 13.35
    Aantal keer de trap30 x59 x
    Afstand volgens Garmin12,51 km25,07 km
    Afstand volgens Strava12,50 km25,07 km
    Afstand volgens Stryd12,50 km25,07 km

    Ik heb de vraag bij Stryd neergelegd waarom dit grote verschil in hoogtemeters kan ontstaan. Er bestaat een Stryd artikel over dit onderwerp die eigenlijk niet zoveel zegt. Ze verwijzen daar naar een interessant artikel van gpsvisualizer.com, om vervolgens te zeggen dat ze deze methoden niet gebruiken.

    Met 2 activiteiten van 1 gebruiker op 1 locatie begrijp ik dat dit niet alle cases van een algoritme kan dekken. Aan de andere kant heb je juist precies een verzameling van dit soort concrete gevallen nodig om verbeteringen te kunnen doen.

    Update 1

    Er kwam vrij vlot antwoord van Stryd waarin ze stellen:

    1. Hoogte data van de pods wordt niet gebruikt wanneer je een activiteit via een Garmin horloge opneemt.
    2. Stryd importeert de activiteit en neemt de hoogtemetingen hieruit over, dus ze pakken wat mijn horloge heeft opnemen.
    3. Stryd past geen correctie algoritme toe (in dit geval) op die geïmporteerde data.
    4. PowerCenter geeft slechts de per-seconde hoogtemetingen weer uit het activiteitenbestand en aggregeert om het totaal weer te geven.
    5. Verder verwezen ze naar dit artikel van Garmin – How do I Change the Elevation Source in Garmin Connect?

    Ik weet dat mijn horloge een barometrische hoogtemeter heeft en inderdaad, als ik de activiteit in Garmin Connect open dan kan ik bij hoogtebron kiezen uit ‘Je toestel’ of ‘Professionele enquêtegegevens’. Deze beide waarden kan ik nu ook opnemen in de tabel door de Garmin regel te splitsen.

    15-02-202513-04-2025
    Garmin fenix 8 softwareVersie 12.38Versie 13.35
    Aantal keer de trap30 x59 x
    Stijging volgens Garmin (toestel)1.049 meter2.071 meter
    Stijging volgens Garmin (enquête)919 meter1.851 meter
    Stijging volgens Strava1.049 meter2.071 meter
    Stijging volgens Stryd870 meter1.823 meter
    Stijging volgens AHN4 (ground truth)1.109,4 meter2.181,82 meter
    Afwijking Garmin (toestel) t.o.v. AHN4-60,4 meter-110,82 meter
    Afwijking Garmin (enquête) t.o.v. AHN4-190,4 meter-330,82 meter
    Afwijking Stryd t.o.v. AHN4-239,4 meter-358,82 meter
    Afwijking Stryd t.o.v. Garmin (toestel)-179 meter-248 meter
    Afwijking Stryd t.o.v. Garmin (enquête)-49 meter-28 meter
    Verhouding afwijking Stryd t.o.v. afwijking Garmin (toestel)3,964 x3,238 x
    Verhouding afwijking Stryd t.o.v. afwijking Garmin (enquête)0,947 x0,985 x

    Nu is de vraag: wat zit er nu daadwerkelijk in een activiteit bestand (.fit bestand)? Laten we erin duiken. Ik gebruik fitfileviewer.com om de details te bekijken van mijn activiteit in april. Onder ‘Activities Metrics’ is in de kolom ’total ascent’ een stijging van 2.071 meter te zien. Dit is het getal dat Garmin en Strava gebruiken voor deze activiteit, en dit is ook het dichtste bij het werkelijke getal van 2.181,82 meter. Dus waarom gebruikt Stryd dit getal ook niet? Ik heb werkelijk geen idee.

    FIT File Viewer

    Ok, wat voor data hebben we nog meer? De daadwerkelijk per-seconde data zit in zowel ‘Record’ als ‘GPS Metadata’. Beide reeksen bevatten het veld ‘enhanced altitude’. Het eerste wat opvalt is dat ze op een verschillende waarde starten (maar wel op dezelfde timestamp). Dan is de tweede vraag hoe hoogteverschillen hieruit afgeleid kunnen worden. Is een positief verschil van een regel ten opzichte van de vorige een stijging en een negatief verschil een daling? Het derde wat ik zie is dat de hoogte die geregistreerd wordt binnen ‘GPS Metadata’ niet met dezelfde waarden verandert als die binnen ‘Record’.

    FIT File Viewer details

    Een plot met beide data reeksen.

    FIT File Viewer vergelijk overzicht

    Zeker als je inzoomt dan wordt het nog duidelijker dat de beide reeksen echt verschillen. Dus welke van de twee reeksen moeten we gebruiken?

    FIT File Viewer vergelijk ingezoomd

    Ik heb wat C# code geschreven om beide series te analyseren. Deze code neemt de som van de hoogteverschillen.

    C#
    using System.Globalization;
    using CsvHelper.Configuration;
    
    const string gpsMetadataFilePath = "/Users/dirk-janmeijer/Downloads/18816702726_ACTIVITY-gps_metadata.csv";
    const string recordFilePath = "/Users/dirk-janmeijer/Downloads/18816702726_ACTIVITY-record.csv";
    using var gpsMetaDataReader = new StreamReader(gpsMetadataFilePath);
    using var recordDataReader = new StreamReader(recordFilePath);
    var config = new CsvConfiguration(CultureInfo.InvariantCulture);
    var usCultureInfo = new CultureInfo("en-US");
    using var gpsMetadataCsv = new CsvHelper.CsvReader(gpsMetaDataReader, config);
    using var recordCsv = new CsvHelper.CsvReader(recordDataReader, config);
    var gpsMetadataItems = gpsMetadataCsv.GetRecords<dynamic>().ToArray();
    var recordItems = recordCsv.GetRecords<dynamic>().ToArray();
    var (gpsMetadataElevationGain, gpsMetadataElevationLoss) = GetElevation(gpsMetadataItems);
    var (recordElevationGain, recordElevationLoss) = GetElevation(recordItems);
    
    Console.WriteLine($"GPS Metadata: {gpsMetadataElevationGain.ToString("#,##0.00", usCultureInfo)} elevation gain, {gpsMetadataElevationLoss.ToString("#,##0.00", usCultureInfo)} elevation loss");
    Console.WriteLine($"Record: {recordElevationGain.ToString("#,##0.00", usCultureInfo)} elevation gain, {recordElevationLoss.ToString("#,##0.00", usCultureInfo)} elevation loss");
    return;
    
    (decimal elevationGain, decimal elevationLoss) GetElevation(dynamic[] items)
    {
        var elevationGain = new List<decimal>();
        var elevationLoss = new List<decimal>();
        foreach (var tuple in items.Zip(items.Skip(1)))
        {
            var firstEnhancedAltitude = GetEnhancedAltitude(tuple.First);
            var secondEnhancedAltitude = GetEnhancedAltitude(tuple.Second);
            var difference = Math.Abs(firstEnhancedAltitude - secondEnhancedAltitude);
            if (firstEnhancedAltitude > secondEnhancedAltitude)
            {
                elevationGain.Add(difference);
            }
            else
            {
                elevationLoss.Add(difference);
            }
        }
    
        return (elevationGain.Sum(), elevationLoss.Sum());
        
        decimal GetEnhancedAltitude(dynamic row) => decimal.Parse(row.enhanced_altitude);
    }
    GPS Metadata: 3,657.20 elevation gain, 3,662.20 elevation loss
    Record: 2,151.20 elevation gain, 2,155.60 elevation loss

    Zoals te zien zit er een heel groot verschil in beide reeksen. De punten binnen ‘GPS metadata’ vertonen veel springerige afwijking en dus telt dit onterecht veel stijging en daling mee. Maar, geen van beide is de 1.823 meter die Stryd rapporteert, of de 1.851 die Garmin (enquête) zegt.

    Op dit punt wordt het wel erg vaag wat Stryd bedoelt als ze zeggen dat ze “de gegevens rechtstreeks vanuit het activiteitenbestand tonen van de per-seconde informatie”. Zijn er andere data punten in het activiteit bestand dat ik over het hoofd zie? Is mijn analyse of de code verkeerd? Ik weet het niet. Ofwel Stryd doet simpelweg een DSM lookup (met welk model?) gegeven de gps lat/long coordinaten, or ze leiden de hoogtemeters stijging en daling op een andere manier af dan de methode die ik hierboven in de code heb gebruikt. Ik gok dat het de eerste optie is.

    Update 2

    Ok, nu wordt het echt interessant want ik realiseerde me zojuist dat de Stryd pods zelf ook activiteiten opnemen, zelfs als je via Garmin opneemt. Deze activiteiten kun je van de pods afhalen en synchroniseren binnen je Stryd account. Omdat mijn activiteiten al via Garmin in mijn Stryd account gesynchroniseerd waren ontstaan er dus dubbele activiteiten. Maar het mooie is dat ik dus ook de originele Stryd data heb en echt antwoord kan geven op de vraag hoe betrouwbaar de hoogte data van Stryd is! De Stryd foot pods hebben namelijk maar 1.641 hoogtemeters geregistreerd tijdens mijn activiteit in april! In werkelijkheid zou dit dus volgens de AHN data 2.181,82 meter moeten zijn.

    Stryd activiteit details

    Helaas heb ik het loopje van februari niet meer van de Stryd pods zelf. Ik denk dat ik deze een keer eerder gesynchroniseerd heb en meteen ontdubbeld (dus verwijderd). De tabel kan ik nog een keer aanvullen, dit keer door de regel van Stryd te splitsen in die met de geïmporteerde activiteit en die van de Stryd pods zelf.

    15-02-202513-04-2025
    Garmin fenix 8 softwareVersie 12.38Versie 13.35
    Aantal keer de trap30 x59 x
    Stijging volgens Garmin (toestel)1.049 meter2.071 meter
    Stijging volgens Garmin (enquête)919 meter1.851 meter
    Stijging volgens Strava1.049 meter2.071 meter
    Stijging volgens Stryd, geïmporteerde activiteit van Garmin870 meter1.823 meter
    Stijging volgens Stryd pods1.641 meter
    Stijging volgens AHN41.109,4 meter2.181,82 meter
    Afwijking Garmin (toestel) t.o.v. AHN4-60,4 meter-110,82 meter
    Afwijking Garmin (enquête) t.o.v. AHN4-190,4 meter-330,82 meter
    Afwijking Stryd pods t.o.v. AHN4-540,82 meter
    Afwijking Stryd pods t.o.v. Garmin (toestel)-430 meter
    Afwijking Stryd pods t.o.v. Garmin (enquête)-210 meter
    Verhouding afwijking Stryd pods t.o.v. afwijking Garmin (toestel)4,88 x
    Verhouding afwijking Stryd pods t.o.v. afwijking Garmin (enquête)1,63 x


    Conclusie: Tijdens mijn loopje in april met 2.181 hoogtemeters, logden de Stryd pods slechts 1.641 hoogtemeters. Dit zit er dus 25% naast!

    Voor de duidelijkheid, ik vind hardlopen op vermogen fijn en denk dat Stryd en de Stryd foot pods hier heel geschikt voor zijn. Ze maken het makkelijk om het juiste tempo aan te houden, geven nauwkeurig race voorspellingen en Stryd is in z’n algemeen gewoon een goed product. Het enige punt is dat ze gemaakt lijken te zijn voor de horizontale wereld, niet voor de verticale.

    Update 3

    Het genoemde Stryd article is offline gehaald. Uiteraard kunnen we deze nog steeds bekijken op https://web.archive.org/web/20241210152803/https://help.stryd.com/en/articles/9010691-elevation-elevation-gain-and-stryd. Ik hoop dat dit betekent dat er binnenkort een nieuwere versie van online wordt gezet die preciezer en duidelijker omschrijft hoe Stryd nu precies met hoogte omgaat.

  • Het Monty Hall probleem

    Het Monty Hall probleem

    Een simpel spelletje. Er is een spelleider en een speler: dat laatste ben jij!

    • Er zijn n deuren. Laten uitgaan van n = 3.
    • Achter 1 van de deuren zit de prijs. Alleen de spelleider weet achter welke deur dat is.
    • Jij moet een deur kiezen.
    • De spelleider opent nu een deur. Hij hanteert hierbij 2 regels:
      1. open niet de deur waar de prijs achter zit
      2. open niet de deur die de speler gekozen heeft
    • Wanneer n > 3 dan zal de spelleider doorgaan met het openen van deuren, gegeven deze 2 regels, totdat er slechts 2 deuren overgebleven zijn.
    • Nu krijg je opnieuw een keuze en dit is de hoofdvraag van het spel: wil je wisselen van deur? Anders geformuleerd: geeft wisselen van deur je op dit moment een grotere kans om te winnen?

    Analyse

    Hoe werkt het? Hoe komen we bij een oplossing?

    • We hebben 3 deuren.
    • ‘P’ betekend dat achter de deur de prijs zit en ‘Y’ betekend dat jij deze deur gekozen hebt.

    Onderstaande tabel bevat nu alle mogelijke scenario’s.

    scenariodeur 1deur 2deur 3
    1P, Y  
    2YP 
    3Y P
    4PY 
    5 P, Y 
    6 YP
    7P Y
    8 PY
    9  P, Y

    Vervolgens opent de spelleider een deur.

    Als we per scenario in bovenstaande tabel kijken wat er bij de 2 resterende deuren overblijft dan zien we dat er 2 opties zijn. Optie 1 is dat jij de deur koos met de prijs erachter en optie 2 is dat jij de deur koos waar de prijs niet achter zit.

    Als we nu gaan tellen hoe vaak beide opties voorkomen krijg we het volgende.

    deur  deuraantal
    P, Y 3
    YP6

    Met deze tabel is het dus triviaal om te zien dat wisselen je een ⅔ kans oplevert om te winnen.

    Wat!?

    Voor mij is dit echt totaal tegenintuïtief. Wanneer je een groot getal voor n neemt, geeft wisselen je bijna 100% kans om de prijs te winnen! Omdat ik mijn eigen analyse niet kon geloven, besloot ik een klein C# consoleprogramma te maken om dit resultaat te valideren en een beetje te spelen met verschillende spelleider strategieën.

    Bekijk de code op Github: Monty-Hall-problem.

  • Mandelbrot afbeeldingen genereren met C#

    Mandelbrot afbeeldingen genereren met C#

    Net als veel andere studenten informatica heb ik software geschreven1 dat afbeeldingen van de Mandelbrot-verzameling rendert. Hoewel mijn implementatie vrij eenvoudig is (een samenvatting met de belangrijkste details wordt hieronder vermeld), is het een goed werkend voorbeeld dat misschien anderen kan helpen die moeite hebben met het renderen van fractals, het implementeren van multithreading of het programmeren in C# in het algemeen.

    Het is behoorlijk verbazingwekkend hoe deze ogenschijnlijk eenvoudige berekening zulke complexe afbeeldingen kan genereren.

    C#
    /// <summary>
    /// This is the core function where the fractal magic happens. It calculates for the given coordinates in the complex plane the mandel number which is used for colouring.
    /// </summary>
    /// <param name="x">Real number.</param>
    /// <param name="y">Imaginairy number.</param>
    /// <returns>Complex number.</returns>
    private int GiveMandelNumber(double x, double y)
    {
        var mandelNumber = 0;
        double a = 0, aOld = 0, b = 0, c = 0;
        while (c <= 4 && mandelNumber < _iterations)
        {
            a = a * a - b * b + x;
            b = 2 * aOld * b + y;
            aOld = a;
            c = a * a + b * b;
            mandelNumber++;
        }
        return mandelNumber;
    }

    Details over mijn implementatie (volgorde is tamelijk willekeurig)

    1. 7 presets (op locaties die ik mooi vind).
    2. Maximaal 60.000 iteraties ondersteund (standaard settings is 400).
    3. Anti-aliasing tot 6 keer (resolutie van 7.200 x 7.200 pixels op high-res displays).
    4. Afbeelding is verdeeld in blokken voor parallelle berekening (standaard blokgrootte is 10, dus de afbeelding wordt vervolgens in 10 * 10 = 100 delen gesneden).
    5. Een voortgangsbalk wordt bijgewerkt die het aantal voltooide blokken aangeeft.
    6. Alle berekeningen worden uitgevoerd door de CPU.
    7. De rode, groene en blauwe tonen kunnen afzonderlijk worden aangepast.
    8. Een gerenderde afbeelding kan worden opgeslagen als PNG, JPEG of BMP.
    9. Sleep met de muis om het gerenderde beeld te verplaatsen.
    10. Dubbelklik links om in te zoomen en dubbelklik rechts om uit te zoomen (zoomfactor is 2).
    11. Maximaal zoomniveau ligt ergens rond 5E-17.

    Op bijna elk punt is er ruimte voor verbetering, maar dat laat ik aan jou over 😁. Je kunt de broncode of het uitvoerbare bestand downloaden op Github.

    1 Onderdeel van het vak “Imperatief programmeren” op de UU.

  • Overzicht gebruikers in Active Directory met notitieveld

    Overzicht gebruikers in Active Directory met notitieveld

    Voor een overzicht van de gebruikers in een bepaalde OU binnen de AD, inclusief de notities, ben je veroordeeld tot een Powershell script.

    Om dit binnen het PS venster weer te geven gebruik je onderstaande code:

    PowerShell
    Get-ADUser -Filter * -SearchBase "OU=Gebruikers,OU=Company,DC=ad,DC=company,DC=com" -Properties Mail, Comment | Sort -Property Name | Format-Table -Wrap -Autosize -Property @{Expression={$_.Name};Label="Gebruikersnaam"}, @{Expression={$_.Enabled};Label="Actief"}, @{Expression={$_.UserPrincipalName};Label="Login naam"}, @{Expression={$_.Mail};Label="E-mail"}, @{Expression={$_.Comment};Label="Notitie"}

    Makkelijker is het om deze direct naar een .csv bestand te gooien.

    PowerShell
    $vandaag = (Get-Date).ToString('yyyy-MM-dd'); Get-ADUser -Filter * -SearchBase "OU=Gebruikers,OU=Company,DC=ad,DC=company,DC=com" -Properties Mail, Comment | Sort -Property Name | Select @{Expression={$_.Name};Label="Gebruikersnaam"}, @{Expression={$_.Enabled};Label="Actief"}, @{Expression={$_.UserPrincipalName};Label="Login naam"}, @{Expression={$_.Mail};Label="E-mail"}, @{Expression={$_.Comment};Label="Notitie"} | Export-CSV "$vandaag-ADGebruikersNotitie.csv" -NoTypeInformation -Encoding unicode

    Ik zal de gebruikte code nog even kort toelichten.

    De kern van het script is het Get-ADUser cmdlet. Standaard geeft deze per gebruiker 10 eigenschappen terug. Te weten: Surname, Name, UserPrincipalName, GivenName, Enabled, SamAccountName, ObjectClass, SID, ObjectGUID en DistinguishedName. Alle extra eigenschappen dien je via de properties parameter mee te geven, in dit geval -Properties Mail, Comment.

    Voor een overzicht van alle eigenschappen van een AD object zie: http://www.kouti.com/tables/userattributes.htm.

    Vervolgens sorteer ik het resultaat op naam: | Sort -Property Name. Daarna vraag ik de volgende velden op (en geef deze een custom naam): Name, Enabled, UserPrincipalName, Mail en Comment.

    Tot slot exporteer ik het geheel naar CSV: | Export-CSV “$vandaag-ADGebruikersNotitie.csv”. Hierbij geeft ik de volgende parameters mee: -NoTypeInformation -Encoding unicode. Deze zorgen ervoor dat er juist met speciale karakters wordt omgesprongen en dat de volgende regel in het CSV bestand wordt weggelaten: #TYPE Selected.Microsoft.ActiveDirectory.Management.ADUser.

  • JavaScript error g_ExpGroupXSLTQueue in SharePoint 2010 lijst

    JavaScript error g_ExpGroupXSLTQueue in SharePoint 2010 lijst

    Dit probleem treedt op doordat SP1 is geinstalleerd terwijl voor SharePoint een actieve taal anders dan Engels geconfigureerd stond. Hierdoor verslikt de userinterface zich bij het uitvouwen van een gegroepeerde lijst. Er doet zich een JavaScript error voor in core.js: ‘g_ExpGroupXSLTQueue’ is undefined.

    Microsoft heeft het probleem onderkent en een Hotfix beschikbaar gesteld: KB 2553117.

  • Snelheid veelgebruikte websites Nederland

    Snelheid veelgebruikte websites Nederland

    Er is veel te doen om de snelheid van een website. Omdat iedereen wel een gevoel heeft bij een bepaalde website wou ik dit eens omzetten naar een klein onderzoekje om dit meetbaar te maken.

    De uitgangspunten hierbij:

    • Waar mogelijk wordt https gebruikt.
    • Waar mogelijk wordt de site opgevraagd als ingelogde gebruiker.
    • Snelheden worden gemeten in seconden tot onload event.
    • Gemeten wordt met Firebug, versie 1.9.2 vanuit Firefox versie 12.0.
    • Metingen worden uitgevoerd van een MacBook, details.
    • Bandbreedte is gelimiteerd tot 5:3, werkelijk gemeten 4,925 Mbps down en 2,845 Mbps up.

    Geteste sites:

    SiteURL
    ANWBhttp://route.anwb.nl/routeplanner/
    Buienradarhttp://www.buienradar.nl
    Facebookhttps://www.facebook.com/
    Google afbeeldingenhttps://www.google.nl/search?q=fiets&tbm=isch
    Google agendahttps://www.google.com/calendar/
    KPNhttps://www.kpn.com/prive/home.htm
    Linkedinhttp://www.linkedin.com/
    Live mailhttps://snt141.mail.live.com/
    Marktplaatshttps://antiek-kunst.marktplaats.nl/antiek-bestek/1000004541-romantic-table-grote-keuze-antieke-bestekken-en-tafelzilver.html
    MSNhttp://nl.msn.com/
    Nu.nlhttp://www.nu.nl/
    onm8http://www.onm8.nl/
    Startpaginahttp://www.startpagina.nl/
    T-mobilehttps://www.t-mobile.nl/My_T-mobile/htdocs/page/LandingPage.aspx
    Tweakers.nethttps://tweakers.net/
    Twitterhttps://twitter.com/
    Uitzendinggemisthttp://www.uitzendinggemist.nl/
    Webwereldhttp://webwereld.nl/
    Wikipediahttps://nl.wikipedia.org/wiki/Fiets
    Youtube moviehttps://www.youtube.com/watch?v=q0UyUdGYS60
    Youtube searchhttps://www.youtube.com/results?search_query=bas+rutten

    Iedere pagina is 20x opgevraagd waarvan 10x via een zachte reload en 10x via een harde reload. De details van deze metingen zijn hier te zien. In onderstaande grafieken zijn de gemiddelde resultaten te zien.

    Harde reload, gem. 5,51 s

    Zachte reload, gem. 3,44 s

    Het belangrijkste zijn de resultaten van de zachte reload. Hierbij zijn de traagste pagina’s die van de ANWB en Buienradar. Deze trekken het gemiddelde behoorlijk omhoog, deze 2 niet meegerekend zou het gemiddelde namelijk op 2,92 seconden liggen.

    Ik denk dan ook dat een laadtijd van 3 seconden een goed praktisch haalbaar gemiddelde is. Overigens zijn de laadtijden van bijvoorbeeld Youtube opvallend, hier worden veel grafische elementen zoals Flash gebruikt maar toch scoren de pagina’s op Youtube gemiddeld ruim onder de 2 seconden.

    De snelheid is van een combinatie van factoren afhankelijk. Snelheid pc, browser, internetverbinding, piekbelasting op server etc. Daarnaast is er ook nog een gebruikerservaring die anders kan zijn dan de onload laadtijden. Bijvoorbeeld bij Live Mail is een gemiddelde laadtijd (zachte reload) gemeten van 5,84 seconden. De gebruikerservaring is hier verbetert doordat de pagina voor een groot deel al zichtbaar is en werkt.

  • Software ontwikkeling in Java, C of C++ met Eclipse op Ubuntu

    Software ontwikkeling in Java, C of C++ met Eclipse op Ubuntu

    Allereerst heb je Ubuntu nodig, deze is te downloaden op de officiele Ubuntu site. Nadat deze geïnstalleerd is open je een terminal venster en voer je de volgende code uit om Eclipse te installeren. Op moment van schrijven betreft het Ubuntu Precise Pangolin (12.04) LTS en Eclipse Indigo (3.7.2).

    1. Eerst Eclipse platform installeren: sudo apt-get install eclipse-platform
    2. Voor de Java Development Tools: sudo apt-get install eclipse-jdt
    3. En voor C/C++ development: sudo apt-get install eclipse-cdt
  • WPA/WPA2 beveiligde Wi-Fi netwerken met enkele uren te kraken

    WPA/WPA2 beveiligde Wi-Fi netwerken met enkele uren te kraken

    Op 27 december 2011 maakte Stefan Viehböck een kwetsbaarheid openbaar in de Wi-Fi Protected Setup functionaliteit. Door deze onvolkomenheid uit te buiten, zo beschreef hij, is het mogelijk om met WPA- of WPA2-wachtwoorden beveiligde Wi-Fi netwerken binnen afzienbare tijd te kraken.

    De volgende dag publiceerde Craig Heffner het programma Reaver onder de GNU GPL 2 licentie. Craig had namelijk (onafhankelijk van Stefan) ook onderzoek gedaan naar de WPS functie, dezelfde kwetsbaarheid ontdekt en al een praktisch inzetbare tool ontwikkeld. Nog diezelfde dag werd Reaver ingediend bij Backtrack om daarin opgenomen te worden. Dit verzoek werd de volgende morgen als eerste werd opgepakt en goedgekeurd.

    En ik kan meedelen, deze methode is verrassend vaak effectief in het wild… 🙂

  • Herstel admin login van CMSMS

    Herstel admin login van CMSMS

    Je wilt inloggen op het admin gedeelte van je CMSMS-website en.. verdorie, je bent het wachtwoord kwijt. Een half uur lang proberen en het enige wat je ziet is: “Gebruikersnaam of wachtwoord incorrect”.

    Om een duistere reden werkt ook de functie ‘Wachtwoord vergeten’ niet dus daarmee valt het probleem ook niet op te lossen. Natuurlijk even googelen en uitkomen bij het volgende artikel op de website van CMS Made Simple zelf: FAQ2 – CMSMS. Goede beschrijving van het probleem inderdaad maar de aangedragen oplossing werkt niet.

    Wat ze daar namelijk zeggen is dat je volgende query moet uitvoeren:

    SQL
    UPDATE cms_users SET PASSWORD = md5('admin') WHERE user_id = 1;

    Wat je dan krijgt is het volgende wachtwoord: 21232f297a57a5a743894a0e4a801fc3.

    Maar zoals gezegd, dat werkt niet.

    Het zit zo.. Tijdens de installatie van CMSMS kun je een gebruikersnaam en wachtwoord kiezen en daarbij kun je (let op, nu komt de clou *tromgeroffel*) met een checkbox kiezen of het wachtwoord versleuteld moet worden. Goed om te weten is dat dit vinkje standaard aan staat.

    Wanneer je het vinkje uit zet wordt je wachtwoord via een standaard md5 functie weggeschreven. Staat het vinkje echter aan, dat wordt er een salt gegenereerd die samen met je gekozen wachtwoord via md5 het password wordt. En precies die salt vergeten ze op de CMSMS wiki.

    Die salt zelf wordt weggeschreven in de tabel siteprefs:

    SQL
    SELECT sitepref_value FROM cms_siteprefs WHERE sitepref_name = 'sitemask';

    Goed, hebben we dat ook helder. Met onderstaande query fix je de hele ellende, je wachtwoord wordt dan: admin. Let hierbij ook ff op dat ik hier de prefix ‘cms_’ gebruik. Dit is de default instelling tijdens de installatie van CMSMS. Welke prefix actief is op jouw site kun je checken in de config.php en dan op zoek naar de $config[‘db_prefix’] variabele.

    SQL
    SET @salt = IFNULL((SELECT sitepref_value FROM cms_siteprefs WHERE sitepref_name = 'sitemask'),'');
    SET @password = 'admin';
    UPDATE cms_users SET password = md5((SELECT CONCAT(@salt, @password))) WHERE user_id = 1;

    Bovengenoemde query werkt met alle versies van CMSMS. Hoewel de sitemask pas in versie 1.10 is toegevoegd zorgt het IFNULL statement voor de compatibiliteit met eerdere versies van CMSMS.

  • Griekse rekensommen

    Griekse rekensommen

    Nog 1 waarschuwing vooraf: de onderstaande berekening kan als schokkend worden ervaren en ernstige vormen van wiskundige desillusie oproepen.

    a = 0,999999...
    10a = 9,99999...
    10a = 9 + 0,999999...
    10a = 9 + a
    9a = 9
    a = 1
    0,999999... = 1