Als je aan een softwareproject wilt bijdragen, dien je vaak eerst een volledige ontwikkelomgeving op te zetten op je computer. GitHub Codespaces neemt je dat uit handen: je zet eenvoudig een ontwikkelomgeving in de cloud op, met toegang vanaf elke computer. Zo weet je zeker dat je overal dezelfde configuratie hebt en onmiddellijk aan de slag kunt.

Als je meehelpt met de ontwikkeling van een of meer softwareprojecten, dan herken je zeker de uitdaging van altijd de juiste ontwikkeltools voorhanden te hebben. Het ene project werkt bijvoorbeeld met Python 3.12, terwijl het andere nog niet compatibel is met Python 3.12. En dan hebben we het nog niet over verschillen in versies van allerlei softwarebibliotheken. Bovendien vragen sommige projecten een nogal omslachtige of complexe installatie van de nodige ontwikkeltools.

Nu kun je als oplossing voor dit probleem deze hele ontwikkelomgeving per project waaraan je meewerkt met Docker in een container draaien. Die container draai je dan lokaal op je computer of in de cloud, waarmee je een consistente ontwikkelomgeving hebt. Je hoeft daardoor zelf niets meer te installeren of up-to-date te houden. Dit principe is uitgewerkt in een specificatie met instellingen voor zogenoemde ontwikkelcontainers, Development Containers, of kortweg devcontainers.

1 GitHub Codespaces

Voor projecten die hun broncode in een repository op GitHub publiceren, is het heel eenvoudig om een devcontainer in de cloud te gebruiken. GitHub biedt deze functionaliteit aan onder de naam GitHub Codespaces. Je start een devcontainer op de servers van GitHub en betaalt per uur dat je die draait en per gigabyte opslag die je gebruikt.

Standaard krijg je 15 GB opslag per maand gratis. Voor een dualcoresysteem geeft GitHub 60 uur gratis per maand weg, wat voor niet-professioneel gebruik zeker moet volstaan.

Verbinden met de codespace doe je of in je browser of in een code-editor, zoals Visual Studio Code. Je stopt een codespace eenvoudig wanneer je 'm niet meer nodig hebt en GitHub stopt ze ook automatisch na een half uur inactiviteit. Je data hierin blijven overigens behouden. Pas na dertig dagen inactiviteit verwijdert GitHub je codespace.

2 Codespace voor een repository

Als je een repository op GitHub in je browser bezoekt, zie je rechts boven de middelste kolom een groene knop Code. Klik je daarop, dan krijg je standaard in het eerste tabblad Local de url’s te zien om de code te ‘klonen’ met Git via https of ssh en de opdracht om hetzelfde te doen met het opdrachtregelprogramma GitHub CLI. Onderaan heb je ook een klassieke downloadlink naar een zip-bestand van de code. Zodra je de code op een van deze manieren op je computer hebt gedownload, sta je dus voor de taak om de ontwikkelomgeving hiervoor te installeren en te configureren.

Maar als je op het tweede tabblad onder Code klikt, met de naam Codespaces, kun je een nieuwe codespace voor de repository aanmaken. Je moet hiervoor wel een (gratis) GitHub-account hebben en ingelogd zijn. We laten in dit artikel zien hoe je een codespace aanmaakt en ermee werkt voor de repository Home Assistant Core. Open hier dus het tabblad Codespaces en klik op de groene knop Create codespace on dev. Die dev staat voor de standaard Git-branch van de repository.

3 Je eerste codespace

GitHub Codespaces maakt nu een codespace voor de repository op basis van de configuratie, doorgaans in de directory .devcontainer. Je krijgt nu een webgebaseerde versie van de code-editor Visual Studio Code in je browser te zien. Helemaal links staat een zijbalk met icoontjes voor de belangrijkste onderdelen van de code-editor, zoals de bestandsverkenner (die standaard open staat), de zoekfunctie en extensies.

Rechts vind je de editor, die standaard het README-bestand van de repository opent. Onderaan zie je de terminal, waarin in het begin een opdracht wordt uitgevoerd om de devcontainer te configureren en alle vereiste ontwikkeltools te installeren. Zodra dat is voltooid, toont de terminal een prompt met je GitHub-gebruikersnaam, de huidige directory en de Git-branch waarin je momenteel werkt, zoals dev. Met een klik op de drie horizontale lijnen linksboven kun je altijd het menu van Visual Studio Code openen.

4 Configuratie van de devcontainer

Als je wilt weten wat de devcontainer op de achtergrond precies opstart, open dan de configuratie. Die staat of in het bestand devcontainer.json in de directory .devcontainer, of in het bestand .devcontainer.json in de bovenste directory van het project. Dit is een JSON-bestand volgens de eerder in dit artikel genoemde specificatie.

In de configuratie vind je onder meer een verwijzing naar het Docker-bestand voor de container, en de opdrachten (vaak shellscripts) die worden uitgevoerd na het maken en starten van de container. Er staat ook in welke poorten de applicatie gebruikt.

Verder vind je in het configuratiebestand een lijst van extensies voor Visual Studio Code die automatisch worden geïnstalleerd bij het aanmaken van de codespace, evenals aangepaste instellingen voor de code-editor.

5 Werken in een codespace

Hoe werk je nu in zo’n codespace? De meeste projecten zijn zodanig geconfigureerd dat je in de zijbalk op het icoontje van het driehoekje met de kever (Run and Debug) kunt klikken en vervolgens bovenaan op het driehoekje (Run). Het programma start dan, met de wijzigingen die je eventueel in de code hebt aangebracht. In de terminal rechtsonder verschijnt de uitvoer van het programma, met eventuele foutmeldingen. Bovenaan in het midden staat een kleine balk met icoontjes om onder meer het programma te herstarten of te stoppen.

Als het gaat om een programma dat netwerkpoorten opent, krijg je deze te zien als je onderaan in plaats van het tabblad Terminal het tabblad Ports kiest. GitHub Codespaces stuurt deze poorten automatisch door naar een domein waarop je ze kunt bezoeken. Ctrl-klik in de lijst met poorten op een url bij de betreffende poort om ze te bezoeken. Mogelijk moet je de applicatie nog wel configureren om met een reverse proxy te werken.

6 Visual Studio Code

Voor wie liever niet in een browser werkt, biedt GitHub Codespaces nog andere mogelijkheden. Gebruik je bijvoorbeeld Microsofts code-editor Visual Studio Code op je computer, installeer daarin dan de extensie GitHub Codespaces. Dat doe je door in Visual Studio Code in de linkerzijbalk op het icoontje van de blokjes (Extensions) te klikken, dan te zoeken naar de extensie GitHub Codespaces en daarbij op Install te klikken.

Klik na de installatie in de zijbalk op het icoontje van het beeldscherm (Remote Explorer), klik bovenaan op het uitklapmenu en kies GitHub Codespaces. Klik daarna op de knop Sign in to GitHub en bevestig in de webpagina die in je browser wordt geopend dat je Visual Studio Code toegang tot je GitHub-account wilt geven. Je krijgt nu in de Remote Explorer al je codespaces te zien. Blijf er even met je muiscursor over hangen en klik dan op het icoontje van de stekker dat verschijnt om met de codespace te verbinden. Dit start de codespace ook op indien deze al is gestopt.

7 Codespaces in Visual Studio Code

Hoewel het in Visual Studio Code lijkt alsof je lokaal werkt, moet je je er goed van bewust zijn dat alle code die je ziet wanneer je met een codespace bent verbonden zich op GitHub Codespaces bevindt. Ook het uitvoeren van de code gebeurt in de cloud en niet op je eigen computer. Bovendien worden alle opdrachten die je in de terminal van Visual Studio Code intypt in de codespace uitgevoerd en niet op je eigen computer.

Om de verbinding met je codespace te verbreken, klik je links weer op het icoontje Remote Explorer en dan op het icoontje van de twee stekkers. Vanaf dat moment werk je weer op je lokale bestandssysteem met Visual Studio Code. Je kunt overigens in Remote Explorer wanneer je met je muiscursor over je codespace blijft hangen de codespace stoppen met een klik op het stopicoontje. Verwijderen kan ook: klik er met rechts op en kies dan Delete Codespace.

Interessant om ook te lezen: Kasm: experimenteren en veilig werken in een geïsoleerde omgeving

8 Op de opdrachtregel

GitHub heeft ook een opdrachtregelprogramma waarmee je in de terminal met je codespaces kunt werken. Volg de installatie-instructies van GitHub CLI en open een nieuw terminalvenster. Log in op je GitHub-account met de opdracht:

Volg de instructies en bevestig in je browser dat je GitHub CLI toegang wilt geven tot je GitHub-account.

Je kunt een lijst opvragen van je huidige codespaces met de opdracht:

Dit toont voor al je codespaces de naam, de repository, de branch en de toestand (actief of gestopt). Je kunt ook met ssh (Secure SHell) op een codespace inloggen. Voer daarvoor deze opdracht uit en selecteer de gewenste codespace uit de lijst:

Indien de codespace niet actief is, wordt deze eerst gestart. Dit werkt alleen als de codespace een ssh-server draait. Je kunt ook een codespace stoppen met deze opdracht (waarbij je achter de optie -c de naam van de codespace opneemt):

9 Standaard devcontainer

Ook voor repository’s die geen configuratie voor een devcontainer hebben, kun je een codespace starten. We illustreren dit met de repository Bluetooth Numbers Database van Nordic Semiconductor. Maak op dezelfde manier als in stap 2 een codespace met een klik op Create codespace on master. De standaardbranch is hier namelijk master.

Omdat de repository geen devcontainer heeft geconfigureerd, start GitHub Codespaces een virtuele machine op met een standaardimage van het besturingssysteem. Daarin zijn de nodige ontwikkeltools voor Python, Node.js, JavaScript, TypeScript, C++, Java, C#, F#, .NET Core, PHP, Go, Ruby en Conda geïnstalleerd. Voor de meeste repository’s kun je dus direct aan de slag om eraan te werken in de cloud.

10 Je eigen devcontainer definiëren

Voor je eigen projecten kun je ook zelf een devcontainer definiëren, waarmee je dan een codespace aanmaakt. De eenvoudigste manier daarvoor is dat je je repository in Visual Studio Code opent, lokaal of terwijl je in een codespace werkt. Doe je dat lokaal, dan moet je eerst de extensie Dev Containers in Visual Studio Code installeren.

Open het opdrachtpalet met Ctrl+Shift+P (of F1 in de browser) en zoek op dev container. Als je lokaal werkt, klik je op Dev Containers: Add Dev Container Configuration Files. Als je in een codespace werkt, klik je op Codespaces: Add Dev Container Configuration Files. Klik op Create a new configuration, waarna je een lijst met enkele voorgedefinieerde devcontainers krijgt. Klik op Show All Definitions om ze allemaal te bekijken. Nu kun je beginnen met typen om te filteren op de gewenste container. Voor een Python-project typ je bijvoorbeeld python, waarna je een van de Python-containers uit de lijst kiest of op het icoontje met de i klikt voor documentatie over de betreffende container.

11 Devcontainer aanmaken

We kiezen hier voor de devcontainer Python 3 devcontainers van het devcontainers-project. Als je erop klikt, kun je nog de versie kiezen. De standaardversie 3.12-bullseye draait Debian 11 (codenaam bullseye) met Python 3.12. Nadat je een keuze hebt gemaakt, kun je nog extra pakketten aanvinken om te installeren. Klik op OK, waarna Visual Studio Code een bestand devcontainer.json in de map .devcontainer aanmaakt.

Als je de repository lokaal in Visual Studio Code hebt geopend, krijg je de vraag om het project opnieuw te openen om het te ontwikkelen in een container. Daarvoor heb je Docker op je computer nodig. Heb je de repository in een codespace geopend, dan zal Visual Studio Code vragen om je container opnieuw te bouwen met de nieuwe configuratie. Klik dan op Rebuild now. Daarna draait je codespace niet meer het standaardimage, maar jouw gekozen image.

12 Aangepaste configuratie

Je kunt het configuratiebestand devcontainer.json nog uitgebreid aanpassen. Voor de documentatie van de mogelijkheden bezoek je het best de specificatie van Development Containers. Met forwardPorts kun je poorten waarop je programma luistert, forwarden naar lokale poorten op je computer. En met postCreateCommand definieer je welke opdrachten er na het aanmaken van de devcontainer moeten worden uitgevoerd. Hierin handel je bijvoorbeeld de installatie van Python-pakketten af die je project nodig heeft.

In customizations kun je instellingen voor een code-editor aanpassen. Voor Visual Studio Code stel je hier bijvoorbeeld in welke extensies je in de codespace wilt installeren. Maar ook instellingen voor de editor zelf zijn hier mogelijk, zoals welke formatter er voor code gebruikt wordt en of die automatisch wordt opgeroepen wanneer je bestanden opslaat.

Iedereen droomt weleens van een thuisbioscoop, maar groter is niet altijd beter. Een te groot scherm kan bijvoorbeeld zorgen voor vermoeide ogen of korrelig beeld. Ontdek hoe zaken als kijkafstand, de resolutie en de kijkhoek bepalen of een televisie daadwerkelijk in je woonkamer past.

In de felverlichte showroom van de elektronicawinkel lijkt die enorme 75-inch televisie waanzinnig indrukwekkend, maar eenmaal aan de muur in een doorsnee Nederlandse doorzonwoning kan zo'n gapend zwart vlak de ruimte volledig domineren. Veel consumenten denken onterecht dat een groter scherm automatisch garant staat voor een betere kijkervaring, ongeacht de afmetingen van de kamer. Toch is er een harde technische grens waarbij groot verandert in té groot, met hoofdpijn en onscherp beeld als direct gevolg. In dit artikel leer je precies hoe je die grens bepaalt en de ideale televisie kiest.

De kern van het probleem: resolutie en blikveld

Het probleem van een te grote tv is niet alleen esthetisch, maar vooral fysiologisch en technisch. Het draait allemaal om de verhouding tussen de resolutie (het aantal beeldpunten) en je blikveld. Zelfs bij moderne 4K-televisies zijn de pixels niet oneindig klein. Als je een enorm scherm neemt en daar te dicht op zit, trek je het beeld als het ware uit elkaar. Hierdoor verliest het beeld zijn scherpte en samenhang; je hersenen moeten harder werken om de losse informatie tot één geheel te smeden.

Een veelgehoorde misvatting is dat je simpelweg went aan elk formaat. Hoewel de eerste shock van een groot scherm inderdaad verdwijnt, blijft de fysieke belasting overeind. Als een scherm meer dan 40 graden van je horizontale blikveld inneemt, kun je niet meer het hele plaatje in één oogopslag zien. Je ogen moeten dan constant van links naar rechts scannen om de actie te volgen, vergelijkbaar met het kijken naar een tenniswedstrijd vanaf de eerste rij. Dat zorgt voor vermoeide ogen en kan op den duur zelfs leiden tot misselijkheid, ook wel 'cybersickness' genoemd.

©Gorodenkoff

Wanneer werkt een groot formaat wél goed?

Er zijn specifieke scenario's waarin een wandvullend scherm niet alleen kan, maar zelfs de voorkeur heeft. Dat geldt vooral als je de televisie primair gebruikt voor hoogwaardige content. Denk hierbij aan films op 4K Blu-ray of streamingdiensten die uitzenden in de hoogste bitrate, en uiteraard gaming op moderne consoles. In deze gevallen is de bronkwaliteit zo hoog dat je dichterbij kunt zitten zonder fouten in het beeld te zien.

Daarnaast werkt een groot formaat goed als de kijkafstand het toelaat. In moderne woningen met een open plattegrond of een loft-indeling staat de bank vaak wat verder van de muur. Als je kijkafstand meer dan 3 meter is, valt een 55-inch televisie al snel in het niet en moet je turen om details te zien. Een 65-inch of groter model herstelt in dat geval de balans en zorgt voor die gewenste bioscoopervaring, waarbij het scherm groot genoeg is om je onder te dompelen zonder dat je individuele pixels ziet.

Wanneer werkt dit níet goed?

De nadelen van een te grote tv worden pijnlijk duidelijk bij 'gewoon' tv-kijken. Veel lineaire televisieprogramma's, zoals het journaal, talkshows of sportuitzendingen via de kabel, worden niet in 4K uitgezonden, maar in Full HD of zelfs nog lager. Een enorme tv vergroot dat signaal genadeloos uit. Op een te groot scherm zie je dan plotseling ruis, compressieblokjes en onscherpe randen die op een kleiner scherm onzichtbaar zouden blijven. Het beeld oogt daardoor onrustig en rommelig.

Ook in de fysieke ruimte kan het tegenvallen. Een tv die uit staat is een groot, zwart en reflecterend vlak. In een compacte woonkamer zuigt een te groot scherm alle aandacht naar zich toe, zelfs als hij uitstaat. Zoiets verstoort de balans in je interieur en kan de kamer kleiner laten aanvoelen dan hij eigenlijk is. Daarnaast is de plaatsing van sfeerverlichting vaak lastiger; een gigantisch scherm blokkeert lichtinval of reflecteert lampen op een storende manier.

©RDVector

Dealbreakers: hier ligt de grens

Er zijn een paar harde grenzen die aangeven dat je beter een maatje kleiner kunt kiezen. Als je een van de onderstaande punten herkent, is dat een duidelijk signaal.

Wat betekent dit voor jouw situatie?

Om te bepalen of een tv past, moet je de rolmaat erbij pakken en even kritisch naar je eigen kijkgedrag kijken. De algemene vuistregel voor 4K-televisies is: meet de afstand van je ogen tot het scherm in centimeters en deel dat door 1,2 tot 1,5. De uitkomst is de ideale schermdiagonaal.

Zit je bijvoorbeeld op 2,5 meter (250 cm) van je scherm? Dan kom je uit op een schermdiagonaal tussen de 166 cm (65 inch) en 208 cm (82 inch). Maar let op: dat geldt alleen voor pure 4K-content. Kijk je veel normale televisie (praatprogramma's, nieuws)? Hanteer dan factor 2. Bij 250 cm afstand kijkt een scherm van 125 cm diagonaal (ongeveer 50 inch) dan vaak prettiger en rustiger. Ben je een fanatieke gamer of filmfanaat? Dan kun je de grens opzoeken. Ben je een casual kijker? Kies dan veilig voor een formaatje kleiner.

©BS | ID.nl

In het kort

Een televisie is te groot wanneer het beeld onscherp oogt of wanneer je fysiek je hoofd moet draaien om alles te kunnen volgen. Hoewel een groot scherm indrukwekkend lijkt, vergroot het bij standaard televisie-uitzendingen ook alle beeldfouten uit. De ideale grootte is een balans tussen kijkafstand en de kwaliteit van wat je kijkt. Meet daarom altijd de afstand tussen bank en muur, en wees realistisch over je kijkgedrag. Zo voorkom je hoofdpijn en blijft tv-kijken ontspannend.

Het is ergens in 2025 als Fable voor het eerst, een soort van, getoond wordt. Beelden volgen elkaar in rap tempo op. We zien de dame die de hoofdrol lijkt te spelen, geen HUD en vooral heel veel mooie filmpjes. Daarna begint het wild speculeren, de klachten over het hoofdpersonage, de vraagtekens over de gameplay. Gelukkig was daar gister de Xbox Developer Direct, waar Microsoft eens te meer bewees de code gekraakt te hebben.

Vóór de pandemie, toen de Electronic Entertainment Expo (E3) nog bestond en online showcases, Directs en State of Plays nog niet echt een ding waren, wisten gameboeren hun spellen prima te verkopen. Ontwikkelaars verschenen op het podium tijdens liveshows, praatten over hun games, speelden live een demo (wat net zo vaak goed als faliekant misging) en dergelijke presentaties werden afgewisseld met teasers, hypetrailers en (nog verder terug) zelfs weleens grafieken en verkoopcijfers. Hoe anders is de wereld anno nu.

Trailers vol trailers

Klaar zitten voor The Game Awards, een gemiddelde Direct, Showcase of Summer Game Fest is leuk, maar niet hetzelfde als ‘toen’. Want de formule is inmiddels bekend. Een half uur, een uurtje, een paar uur lang wordt er de ene na de andere trailer op je hersenen afgevuurd. Wat is ‘reclame’ en wat niet? Geen idee. Standaard zijn de animegames die elkaar zo rap opvolgen dat de gemiddelde kijker niet eens meer weet waar de ene game begint en de ander ophoudt. Meestal zit er een klapper aan het begin, waarna het grote wachten op de klapper aan het einde begint.

Vraag iemand een week later wat ie gezien heeft, en meer dan de helft van de getoonde games is waarschijnlijk uit het geheugen verdwenen.  En al die flarden van beelden zonder fatsoenlijke uitleg leiden vaker wel dan niet tot hetzelfde als die ene soort van trailer van Fable: speculaties, wild geroep en vraagtekens. Het komt de online discussie rondom games niet ten goede.

©Playground Games

Hoe anders was de inmiddels traditionele Xbox Developer Direct. Langer dan een uur, voor maar vier games. Die games kregen zodoende alle tijd, net als de ontwikkelaars. Gameplaybeelden zijn niet aan te slepen, verscheidene modi worden uitgebreid besproken en zelfs de kleinste details krijgen meer dan genoeg ademruimte. Zo horen we tijdens de Forza Horizon 6-presentatie dat het nummer van je eigen hangar (78) gekozen is omdat de game zich afspeelt in Japan, en die cijfers daar een positieve lading hebben. Fijn om te horen hoe scherp het oog voor detail van een ontwikkelaar is. Dat zegt iets over het project. En het is ook iets wat je never nooit in een hypetrailer van anderhalve minuut langs had zien komen.

Trailers vol trailers

En dus zit ik gisteravond te genieten. Niet eens per se van de games, want ze vallen net niet in mijn straatje. Forza Horizon 6 vind ik héél indrukwekkend en de game zal ongetwijfeld miljoenen spelers perfect bedienen, maar ik ben niet zo van het racen. Game Freak - de makers van Pokémon die eindelijk hun vleugels uitslaan met graphics uit dit decennium - komen met Beast of Reincarnation. Het ziet er oké uit. Double Fine vindt in mij ook geen fan en een multiplayer-pottenbakgame (Kiln) is niet iets wat hoog op mijn lijstje stond. Zelfs afsluiter Fable wist me met z’n levenssimulaties ook niet te overtuigen. Maar, nogmaals, wat heb ik genoten. Van ontwikkelaars die ruim de tijd kregen. Van de games, die van alle kanten belicht werden. Van de antwoorden die we kregen.

©Playground Games

Want wat ik nou precies van die games vond, is niet eens zo heel belangrijk. Veel belangrijker is dat iedereen dit keer in ieder geval een uitgebreid beeld kreeg van wat deze games nu precies worden. Een Xbox Developer Direct creëert geen valse hype. Van die vier getoonde games, weten we nu eigenlijk alles wat we redelijkerwijs moeten weten. Zoals bijvoorbeeld dat Fable een character creation-modus heeft, om maar iets te noemen. En plots zie je de discussies rondom de games gaan om… de inhoud. En niet op wilde speculaties rondom hoofdpersonages die helemaal niet vast blijken te staan. Love it.