Hoe valideer je een lijst met posities en bereikformaten in je programma?

Bij het ontwikkelen van software die afhankelijk is van de invoer van een gebruiker, zoals een lijst met posities of bereiken, komt het vaak voor dat er variaties in de manier waarop gegevens worden ingevoerd. Het is essentieel om de invoer te valideren en correct te verwerken, zodat de gebruiker niet voor onverwachte fouten komt te staan. De volgende uitleg behandelt hoe je zo'n invoer kunt parseren en valideren, met gebruik van Rust en enkele specifieke technieken.

Een voorbeeld van invoer kan eruit zien als volgt: "1,3", "1-3", of zelfs "001,0003". De eerste stap is het splitsen van de invoer op basis van komma's, zodat we individuele waarden kunnen verwerken. De parser moet elke waarde afzonderlijk kunnen verwerken en, indien nodig, het formaat aanpassen naar een zero-based index (waarbij de tel begint vanaf nul in plaats van één). Dit kan worden gedaan door een functie te schrijven die de waarden controleert en converteert naar een correcte index.

De functie parse_pos kan deze taak uitvoeren door te kijken naar het formaat van de invoer. Als de invoer bijvoorbeeld een bereik bevat, zoals "1-3", moet de functie niet alleen de individuele waarden valideren, maar ook controleren of het bereik logisch is (dus dat de beginwaarde kleiner is dan de eindwaarde). Dit kan eenvoudig worden gerealiseerd met behulp van een reguliere expressie om te controleren of een reeks van twee cijfers correct is en het bereik zelf te valideren.

Een voorbeeld van zo'n functie in Rust zou er als volgt uitzien:

rust
Copy code
fn parse_pos(range: String) -> Result<Vec<Range<usize>>, anyhow::Error> {

    let range_re = Regex::new(r"^(\d+)-(\d+)$").unwrap();

    range
        .split(',')
        .into_iter()
        .map(|val| {
            parse_index(val).map(|n| n..n + 1).or_else(|e| {

                range_re.captures(val).ok_or(e).and_then(|captures| {

                    let n1 = parse_index(&captures[1])?;

                    let n2 = parse_index(&captures[2])?;

                    if n1 >= n2 {
                        bail!(
                            "First number in range ({}) must be lower than second number ({})",
                            n1 + 1,
                            n2 + 1
                        );
                    }
                    Ok(n1..n2 + 1)
                })
            })
        })
        .collect::<Result<Vec<_>, _>>()
        .map_err(From::from)
}

In dit voorbeeld wordt een reguliere expressie gebruikt om een bereik van twee getallen (gescheiden door een streepje) te herkennen. Als het bereik niet geldig is (bijvoorbeeld als het eerste getal groter is dan het tweede), wordt er een foutmelding gegenereerd die uitlegt wat er mis is met de invoer.

Naast de technische implementatie is het ook belangrijk om te overwegen hoe de gebruikersinterface de foutmeldingen zal presenteren. Dit kan een grote impact hebben op de gebruikerservaring. In plaats van generieke foutmeldingen zoals "ongeldige invoer", kan het gebruik van specifieke foutberichten, zoals "illegal list value: 'foo'", helpen de gebruiker precies te informeren over wat er mis is met hun invoer. Door gebruik te maken van enum-varianten en aangepaste foutmeldingen, kan de applicatie zowel technisch robuust als gebruiksvriendelijk zijn.

Met de bovenstaande functies kunnen we de invoer van de gebruiker succesvol valideren en verwerken. Zodra de parser is geïmplementeerd en de invoer correct wordt verwerkt, kan deze vervolgens worden gebruikt in andere delen van het programma om de gewenste functionaliteit te realiseren. Bijvoorbeeld, wanneer een geldige invoer is ontvangen, kan de programma-uitvoer een specifiek bereik of een lijst van velden extraheren, afhankelijk van de ingevoerde waarden. Dit kan visueel of programmatisch gepresenteerd worden, afhankelijk van de vereisten van de applicatie.

Het is echter belangrijk om verder te kijken dan alleen de technische implementatie en het correct verwerken van invoer. Er moet ook aandacht worden besteed aan de documentatie en de communicatie van de fouten aan de gebruiker. Bij het schrijven van software is het essentieel om altijd in gedachten te houden dat de gebruiksvriendelijkheid en de duidelijkheid van de foutmeldingen een cruciale rol spelen in de algehele kwaliteit van de applicatie. Een goed gestructureerde en informatieve foutmelding kan de gebruiker enorm helpen bij het oplossen van problemen zonder dat ze het gevoel krijgen vast te lopen.

Hoe vergelijk je regels uit twee bestanden in Rust met behulp van iterators?

In de wereld van de programmeertaal Rust is het verwerken van bestanden en het vergelijken van hun inhoud een taak die vaak voorkomt bij verschillende toepassingen. Een veelvoorkomend scenario is het vergelijken van de regels van twee bestanden om te bepalen welke regels uniek zijn voor elk bestand, welke overeenkomen, en welke niet. Dit wordt vaak gedaan met behulp van iterators. In deze context gaan we dieper in op hoe je dit proces efficiënt kunt beheren, zelfs als de bestanden een ongelijke lengte hebben, en hoe je met specifieke kenmerken zoals hoofdlettergevoeligheid en ordening omgaat.

In een eenvoudig geval waarin we twee bestanden willen vergelijken, moeten we de inhoud van deze bestanden in een geordende manier verwerken. De uitdaging komt vooral naar voren wanneer de bestanden verschillende lengtes hebben. De kern van het probleem is dat je de regels van beide bestanden tegelijkertijd moet lezen en vergelijken, maar het ene bestand kan eerder het einde bereiken dan het andere. Een oplossing hiervoor is het gebruik van iterators die ervoor zorgen dat de verwerking van beide bestanden soepel verloopt, ongeacht hun grootte.

Het opzetten van iterators voor bestandshandles

Om dit te bereiken, kun je iterators gebruiken voor het lezen van de lijnen uit elk bestand. In de Rust-taal is dit eenvoudig te implementeren door de lines() functie te gebruiken op bestandshandles. Wanneer je twee bestandshandles hebt, kun je voor beide bestanden een iterator maken die over de regels heen gaat. Maar voordat je de regels gaat vergelijken, is het belangrijk om te begrijpen hoe je met specifieke scenario’s zoals hoofdlettergevoeligheid omgaat. Als je wilt dat de vergelijking hoofdletterongevoelig is, kun je een closure gebruiken die elke regel omzet naar kleine letters, afhankelijk van een instelling die door de gebruiker wordt meegegeven.

Werken met verschillende bestandsgroottes

Vergelijken van de regels

Bij het vergelijken van de regels uit twee bestanden, zijn er verschillende mogelijkheden die we moeten behandelen. De regels kunnen gelijk zijn, in dat geval wil je de regel één keer afdrukken en beide iterators vooruit laten gaan. Wanneer een van de regels kleiner is dan de andere (volgens de lexicografische volgorde), wil je de kleinere regel afdrukken en de iterator voor dat bestand verder laten gaan. Dit kan bereikt worden door de cmp methode van de Ord trait te gebruiken. Dit maakt het mogelijk om de regels op basis van hun ASCII-waarden te vergelijken en te bepalen welke eerst moet worden afgedrukt.

In Rust kan dit proces worden geïmplementeerd met de cmp functie, die de twee waarden vergelijkt en een resultaat oplevert dat aangeeft of de eerste waarde kleiner, gelijk of groter is dan de tweede. Het resultaat van deze vergelijking wordt vervolgens gebruikt om te bepalen welke regel eerst moet worden afgedrukt.

Afdrukken van de resultaten

Er is echter meer te overwegen. Soms kan het nuttig zijn om de uitvoer te formatteren op een manier die beter leesbaar is. Bijvoorbeeld, de uitvoer van een programma dat twee bestanden vergelijkt kan worden gepiped naar een tool zoals sed om tabs te vervangen door een speciaal teken zoals --->, wat de kolommen visueel duidelijker maakt.

Het implementeren van het algoritme

In de praktijk komt de implementatie van dit algoritme neer op het gebruik van een while loop die blijft itereren over de regels van beide bestanden zolang ten minste één van de iterators een regel bevat. Door de verschillende gevallen te matchen—wanneer beide regels aanwezig zijn, wanneer er slechts één regel aanwezig is, of wanneer er geen regels meer zijn—kun je de logica schrijven om de regels correct af te drukken. Door de waarden van de regels te vergelijken en te bepalen welke eerst moet komen, kun je precies nabootsen hoe het comm-commando in Unix-besturingssystemen werkt.

Naast de techniek zelf is het belangrijk om de gebruikerservaring te overwegen. Bij het implementeren van deze logica, is het essentieel om na te denken over hoe je foutmeldingen en uitzonderingen afhandelt, bijvoorbeeld wanneer een van de bestandshandles niet geopend kan worden of wanneer er problemen zijn met de leesbaarheid van de bestanden. Het is ook handig om de mogelijkheid van hoofdlettergevoeligheid in te bouwen, afhankelijk van de behoeften van de gebruiker, wat een belangrijke overweging kan zijn bij het vergelijken van tekstbestanden die hoofdlettergevoelig of ongevoelig moeten zijn.

Hoe kun je een maand- of jaarweergave maken in de terminal met Rust?

In Rust is het mogelijk om een kalender te genereren die je maand- of jaarweergave in de terminal toont. Dit vereist een aantal nuttige technieken, waaronder het gebruik van de chrono crate voor datum- en tijdbeheer, en functies zoals Vec::chunks en Iterator::zip voor het organiseren van data in gestructureerde formaten. Het uiteindelijke doel is om een weergave te creëren die kan worden aangepast aan de gebruiker, zoals het tonen van speciale datums of het aanpassen van de indeling van de kalender.

Wanneer we werken met een maandweergave, beginnen we met het verkrijgen van de huidige maand en het jaar. Het is belangrijk om te begrijpen dat maanden in veel programmeertalen (inclusief Rust) beginnen bij 0 (januari = 0, februari = 1, enzovoorts). Dit betekent dat we de maand moeten omrekenen naar een positieve waarde die we vervolgens kunnen gebruiken om de naam van de maand en de bijbehorende dagen correct weer te geven.

Voor het afdrukken van een volledige jaarkalender wordt eerst het jaar in de bovenste regel gezet. Vervolgens wordt elke maand van het jaar geformatteerd, maar zonder het jaartal in de koptekst van elke maand. Dit is een subtiele wijziging die ervoor zorgt dat de weergave overzichtelijk blijft en niet te druk wordt. De maanden worden in groepen van drie weergegeven, zodat de kalender per regel een "blok" van drie maanden toont. Dit wordt bereikt door Vec::chunks te gebruiken, en vervolgens worden de maanden samengevoegd met behulp van de itertools::izip macro. Deze macro stelt ons in staat om meerdere iterators te combineren, zodat we gelijktijdig de bijbehorende regels van elke maand kunnen afdrukken.

Er zijn verschillende manieren waarop deze kalender verder kan worden aangepast. Zo kun je bijvoorbeeld een configuratiebestand aanmaken in de thuismap van de gebruiker, zoals $HOME/.calr, waarin speciale data zoals feestdagen of verjaardagen kunnen worden opgeslagen. Met behulp van terminalkleurformattering kun je deze datums bijvoorbeeld in het vet, omgekeerd of gekleurd weergeven om ze te benadrukken. Dit kan de kalender niet alleen functioneel maken, maar ook visueel aantrekkelijker en persoonlijker voor de gebruiker.

Daarnaast kun je overwegen om de functionaliteit van de kalender uit te breiden naar internationale omgevingen. Door gebruik te maken van omgevingsvariabelen zoals LANG of LANGUAGE, zou je de maandnamen in de voorkeurstaal van de gebruiker kunnen weergeven. Dit is bijzonder belangrijk voor gebruikers die verschillende scripts gebruiken, zoals Chinees, Japans of Cyrillisch. Het zou zelfs mogelijk zijn om de kalender in een rechter-naar-links leesbare vorm weer te geven voor talen zoals Hebreeuws of Arabisch, of zelfs om een Mongoolse kalender te creëren die van boven naar beneden leest.

Tot slot zou je de kalender kunnen combineren met andere nuttige terminalprogramma’s. Zo kan een programma zoals date dat de huidige datum en tijd toont, worden gemodelleerd in Rust. Dit zou een interessante uitbreiding zijn voor gebruikers die veel werken met datums en tijd en die op zoek zijn naar een krachtig, op maat gemaakt hulpmiddel voor hun dagelijkse taken.

Hoe test je een programma als ls in Rust?

Bij het schrijven van een programma als ls in Rust komt er veel kijken bij het testen van de uitvoer. De dynamiek van de bestands- en directoryinformatie, zoals eigenaar, grootte en permissies, maakt het noodzakelijk om flexibele en robuuste testmethoden te ontwikkelen. In dit hoofdstuk bespreken we hoe je tests schrijft voor een programma dat directory-informatie op dezelfde manier weergeeft als het klassieke ls, maar in de context van Rust, waarbij verschillende uitdagingen zich voordoen afhankelijk van het systeem waarop je werkt.

Het basisprincipe van testen

Het programma werkt door het ophalen van metadata van bestanden en directories. Deze metadata bevat onder andere het bestandssysteem-ID, de gebruikers-ID, groeps-ID, permissies, en de datum van de laatste wijziging. Een van de eerste testuitdagingen is het verifiëren van deze metadata op verschillende systemen. Aangezien bestandspermissies, bestandsgrootte en eigenaren op elk systeem kunnen variëren, wordt de testfunctie ontwikkeld om deze variabiliteit aan te pakken zonder de logica van het programma te verstoren.

Om te beginnen wordt er gebruikgemaakt van de functie run_long die specifiek kijkt naar de bestandspad, permissies en bestandsgrootte. Hierbij wordt een Command uitgevoerd die het programma uitvoert met specifieke parameters en de uitvoer wordt vergeleken met de verwachte resultaten. Dit is een essentieel onderdeel van de testlogica, want het programma moet de juiste permissies en bestandsgrootte weergeven, en dat moet precies worden gecontroleerd.

Testen van de uitvoer

In de volgende testfunctie wordt gecontroleerd of de uitvoer van het programma overeenkomt met de verwachte waarden. De uitvoer wordt door middel van een Command uitgevoerd, de standaard uitvoer wordt omgezet in een UTF-8 string en vervolgens gesplitst in verschillende componenten. Het programma controleert of de permissies van het bestand correct zijn, of de bestandsgrootte overeenkomt met de verwachte waarde en of de bestandsnaam juist wordt weergegeven.

rust
Copy code
fn run_long(filename: &str, permissions: &str, size: &str) -> Result<()> {
    let cmd = Command::cargo_bin(PRG)?
        .args(&["--long", filename])
        .assert()
        .success();
    let stdout = String::from_utf8(cmd.get_output().stdout.clone())?;

    let parts: Vec<_> = stdout.split_whitespace().collect();

    assert_eq!(parts.get(0).unwrap(), &permissions);

    assert_eq!(parts.get(4).unwrap(), &size);

    assert_eq!(parts.last().unwrap(), &filename);
    Ok(())
}

Deze aanpak heeft een duidelijke focus op de te testen elementen. De test is eenvoudig te begrijpen: je voert een opdracht uit die ls nabootst met de --long vlag en controleert of de relevante kolommen zoals bestandspermissies, bestandsgrootte en bestandsnaam correct worden weergegeven.

Het testen van directories vereist echter wat extra aandacht. Dit komt omdat directorygroottes vaak variëren afhankelijk van het besturingssysteem, dus wordt de directorygrootte genegeerd in de test. De permissies en het pad worden echter wel gecontroleerd.

rust
Copy code
fn dir_long(args: &[&str], expected: &[(&str, &str, &str)]) -> Result<()> {

    let cmd = Command::cargo_bin(PRG)?.args(args).assert().success();
    let stdout = String::from_utf8(cmd.get_output().stdout.clone())?;
    let lines: Vec<&str> = stdout.split("\n").filter(|s| !s.is_empty()).collect();
    assert_eq!(lines.len(), expected.len());
    let mut check = vec![];
    for line in lines {

        let parts: Vec<_> = line.split_whitespace().collect();

        let path = parts.last().unwrap().clone();
        let permissions = parts.get(0).unwrap().clone();

        let size = match permissions.chars().next() {

            Some('d') => "",
            _ => parts.get(4).unwrap().clone(),
        };
        check.push((path, permissions, size));
    }
    for entry in expected {
        assert!(check.contains(entry));
    }
    Ok(())
}

In dit geval worden de directories correct gecontroleerd zonder rekening te houden met de grootte, maar worden wel de permissies en het pad geverifieerd. Dit toont aan hoe belangrijk het is om flexibel om te gaan met systeemverschillen tijdens het testen.

Het belang van systeemcompatibiliteit

Wanneer we testen, moeten we altijd rekening houden met het feit dat uitvoer van programma's als ls kan variëren tussen verschillende systemen. Dit geldt vooral voor bestandsgroottes van directories, en ook voor de gebruikers- en groepsnamen, die korter of langer kunnen zijn afhankelijk van het systeem. Deze variabelen kunnen de opmaak van de uitvoer beïnvloeden, maar de kerninformatie, zoals bestandspermissies en bestandsgrootte, blijft de focus van de test.

Daarom is het belangrijk om tests te ontwikkelen die robuust zijn en systeemonafhankelijk kunnen opereren. Dit betekent dat de tests altijd het juiste resultaat moeten geven, ongeacht de specifieke waarden die worden gerapporteerd door het systeem waarop ze draaien. Dit kan worden bereikt door het testen van de basiselementen zoals pad, permissies, en bestandsgrootte, en door zorgvuldig om te gaan met de formattering van de uitvoer.

Verdere stappen

Zodra je je tests hebt geschreven en getest, kun je verder gaan met het verbeteren van je programma. Voeg meer functionaliteit toe die overeenkomt met de opties van ls, en zorg ervoor dat elke nieuwe functie goed wordt getest. Hierbij kun je inspiratie halen uit andere implementaties van ls in Rust, zoals exa en lsd, of zelfs nieuwe tools zoals tree, die een boomstructuur van bestanden en directories weergeven.