🍾

Release Candidate

Sprint 18

Inhoudsopgave

  • Repositories
  • Week 1
    • Software Release Life Cycle (SRLC)
    • Geen TLA's meer!
    • GSAB
  • Week 2
    • Clean code
    • Refactoring
  • Week 3
    • Three.js
    • Van offerte naar productie
  • Bronnen

Repositories

Week 1 | 06 t/m 10 januari

Dit is de laatste sprint waarin we les krijgen op school. De komende colleges mochten we zelf invullen met onderwerpen waar we graag meer over wilden leren.

Software Release Life Cycle (SRLC)

De Software Release Life Cycle beschrijft het proces van het ontwikkelen, testen en distribueren van software. Dit proces bestaat doorgaans uit de volgende fases:

  • Pre-alpha: In deze fase wordt de software ontworpen en gebouwd. Dit is een vroege ontwikkelingsfase waarin nog geen uitgebreide tests worden uitgevoerd.
  • Alpha: De eerste fase van formele tests. Hier wordt de software intern getest binnen de organisatie. Het doel is om initiële fouten op te sporen.
  • Beta: Een grotere gebruikersgroep buiten de organisatie test de software. De focus ligt op het verzamelen van gebruikersfeedback en het minimaliseren van gebruiksproblemen.
  • Release Candidate (RC): Ook wel "gamma testing" of "going silver" genoemd. Dit is een versie die bijna klaar is voor release, tenzij ernstige bugs worden ontdekt. Alle functies zijn geïmplementeerd en getest.
  • Final Release ("Gold"): De uiteindelijke versie van de software die publiek beschikbaar wordt gemaakt.

Code-Complete:

Wanneer een release als code-complete wordt beschouwd, betekent dit dat er geen nieuwe broncode meer wordt toegevoegd. Er kunnen nog wel bugfixes en updates voor documentatie worden doorgevoerd.

Geen TLA's meer!

Hieronder een overzicht van enkele belangrijke termen:

  • CSR (Client-Side Rendering): De browser laadt een leeg HTML-bestand en gebruikt JavaScript (JS) en CSS om verbinding te maken met de backend. Daarna wordt de pagina gerenderd.
  • SSR (Server-Side Rendering): Bij elke aanvraag wordt de HTML op de server gerenderd en als complete pagina naar de browser gestuurd.
  • SSG (Static Site Generation): Tijdens het buildproces worden alle mogelijke pagina's vooraf gerenderd. Het resultaat is een statische website die eenvoudig te hosten is.
  • ISR (Incremental Static Regeneration): Een variant van SSG waarbij de build periodiek wordt uitgevoerd. Alleen pagina's met gewijzigde content worden opnieuw gerenderd.
  • CDN (Content Delivery Network): Een netwerk van servers die statische bestanden snel en efficiënt naar gebruikers verspreiden.
  • CI (Continuous Integration): Een ontwikkelpraktijk waarbij codewijzigingen automatisch worden getest en geïntegreerd in de hoofdcodebase.

GSAP

GSAP is een krachtige en flexibele JavaScript-bibliotheek die speciaal is ontworpen voor het maken van animaties op het web. Het wordt beschouwd als een industriestandaard voor webanimaties vanwege de hoge prestaties en veelzijdigheid.

Belangrijkste kenmerken van GSAP:

  • Hoge performance: GSAP biedt vloeiende animaties, zelfs op apparaten met lagere specificaties, en is geoptimaliseerd voor moderne browsers.
  • Efficiënt gebruik van CSS: Waar mogelijk maakt GSAP gebruik van CSS-transformaties (zoals transform en opacity) om animaties efficiënter te maken.
  • JavaScript voor meer controle: Wanneer iets niet mogelijk is met CSS alleen, schakelt GSAP over op JavaScript voor precieze controle en complexere animaties.
  • Geoptimaliseerde prestaties: Alle animaties zijn uiterst geoptimaliseerd om soepel te werken, ongeacht de complexiteit van de animatie.

Waarom GSAB?

  • Hoge performance: GSAP biedt vloeiende animaties, zelfs op apparaten met lagere specificaties, en is geoptimaliseerd voor moderne browsers.
  • Efficiënt gebruik van CSS: Waar mogelijk maakt GSAP gebruik van CSS-transformaties (zoals transform en opacity) om animaties efficiënter te maken.
  • JavaScript voor meer controle: Wanneer iets niet mogelijk is met CSS alleen, schakelt GSAP over op JavaScript voor precieze controle en complexere animaties.
  • Geoptimaliseerde prestaties: Alle animaties zijn uiterst geoptimaliseerd om soepel te werken, ongeacht de complexiteit van de animatie.
  • Breed scala aan animaties: Het ondersteunt een breed scala aan animaties, van eenvoudige bewegingen tot geavanceerde tijdlijnen.
  • Gemakkelijke integratie: Het kan gemakkelijk geïntegreerd worden met frameworks zoals React, Vue en Angular.
  • Actieve community en documentatie: GSAP heeft een actieve community

Week 2 | 13 t/m 17 januari

Clean Code

Het schrijven van clean code is een essentiële vaardigheid voor elke professional in softwareontwikkeling. Het stelt je in staat om code te creëren die niet alleen functioneel is, maar ook begrijpelijk en onderhoudbaar. Hieronder worden de belangrijkste principes en richtlijnen voor clean code uitgelegd.

Wat is Clean Code?

    Clean code is code die:
  • Gemakkelijk te begrijpen is door iedereen in het team.
  • Leesbaar, aanpasbaar, uitbreidbaar en onderhoudbaar is.
  • Kan worden gelezen en verbeterd door andere ontwikkelaars, ook als zij niet de oorspronkelijke auteurs zijn.

Tips voor Clean Code

1. Gebruik duidelijke namen

  • Kies beschrijvende en betekenisvolle namen voor variabelen, functies en bestanden.
  • Vermijd cryptische afkortingen of generieke namen zoals a, x, data, of temp.

2. Schrijf kleine functies

  • Houd functies klein: een functie zou slechts één verantwoordelijkheid moeten hebben (volg het Single Responsibility Principle).
  • Minimaliseer het aantal parameters:
    • Voorkeur voor monadische functies (één parameter).
    • Gebruik diadische functies (twee parameters) indien nodig.
    • Vermijd triadische functies (drie parameters) of meer.
  • Vermijd side-effects: een functie moet alleen werken met de meegegeven parameters en een duidelijke output teruggeven.

3. Gebruik goed commentaar

  • Less is more: Schrijf code die zichzelf uitlegt, zodat weinig commentaar nodig is.
  • Gebruik commentaar alleen als extra context noodzakelijk is.
  • Verwijder uitgecommentarieerde code uit de codebase; gebruik versiebeheer (bijvoorbeeld Git) om eerdere versies te raadplegen.

4. Maak code leesbaar

  • Code wordt vaker gelezen dan geschreven. Zorg dat het intuïtief en helder is.
  • Gebruik consistente stijl, inspringing, en witruimte.
  • Volg de code-conventies binnen je team of organisatie.

5. Kleine opruimacties

Het verbeteren van code hoeft geen grote verandering te zijn. Kleine acties maken een verschil:

  • Hernoem één variabele naar een duidelijkere naam.
  • Splits een te grote functie op.
  • Elimineer een kleine duplicatie.
  • Maak samengestelde if-statements overzichtelijker.

Refactoring

Refactoring is het proces van het verbeteren van de structuur van code zonder het gedrag ervan te veranderen. Het doel is om de code:

  • Leesbaarder,
  • Eenvoudiger te begrijpen,
  • Makkelijker onderhoudbaar, en
  • Uitbreidbaar te maken.

Belangrijke Refactoring-patronen

1. Hernoem functie declaratie

  • Verander de naam, parameters, of volgorde van parameters van een functie om deze beter te laten aansluiten bij de behoeften van de codebase.
  • Dit verbetert de leesbaarheid, begrijpelijkheid en testbaarheid van de code.

2. Verwijder dode code

  • Identificeer en verwijder overbodige of ongebruikte functies, variabelen of klassen.
  • Dit voorkomt dat ontwikkelaars worden afgeleid door irrelevante of verouderde onderdelen, en verbetert de onderhoudbaarheid van de codebase.

3. Verschuif statements

  • Plaats gerelateerde statements dichter bij elkaar.
  • Verplaats irrelevante of afleidende stukken code naar een geschiktere locatie.
  • Door statements logisch te ordenen wordt de structuur van methoden duidelijker, wat leidt tot beter begrip en eenvoudiger onderhoud.

Voorbeeld:

// Voor refactoring
const pricePlan = retrievePricePlan();
const order = retrieveOrder();
let charge;
const chargePerUnit = pricePlan.unit;

// Na refactoring
const pricePlan = retrievePricePlan();
const chargePerUnit = pricePlan.unit;
const order = retrieveOrder();
let charge;

Week 3 | 20 t/m 24 januari

Three.js

Three.js is een krachtige JavaScript-bibliotheek waarmee je 3D-graphics kunt maken in de browser. Hieronder vind je een overzicht van de belangrijkste concepten en basiselementen van Three.js.

Camera

De Camera bepaalt het perspectief van waaruit je de 3D-wereld bekijkt. Er zijn twee veelgebruikte cameratypes:

  • Perspective Camera: Deze camera simuleert diepte zoals het menselijk oog dat doet. Perfect voor realistische 3D-scenes.
  • Orthographic Camera: Deze camera heeft geen perspectivische vervorming, waardoor objecten dezelfde grootte blijven ongeacht hun afstand.

Render

De Renderer zorgt ervoor dat de 3D-scène daadwerkelijk wordt weergegeven in de browser. De meest gebruikte renderer in Three.js is de WebGLRenderer.

Belangrijke Componenten

  • Mesh: Een Mesh combineert geometrie (de vorm van een object) en materiaal (hoe het object eruitziet) om een renderbaar object te creëren.
  • Light: Light (licht) is essentieel voor het bepalen van hoe objecten worden verlicht en weergegeven in de scène. Er zijn verschillende soorten lichten zoals Ambient Light, Point Light, en Directional Light.
  • Shader: Een Shader is een stukje code dat bepaalt hoe pixels op het scherm worden weergegeven. Met shaders kun je aangepaste visuele effecten creëren.

Van offerte naar productie

Timeline

Vraag, Gesprek, Offerte, Design, Development, Oplevering, SLA

Hoe kom je aan projecten?

Je hebt een netwerk nodig

  • Klas genoten
  • Collega’s op je werk
  • Vrienden, familie en kennissen

Wat wil de opdrachtgever (echt)

  • Briefing
  • Verwachtingen
  • Wat kan jij, wat kan ik
  • Nee zeggen, wil ik dit wel?

Vragen die je kan stellen aan de klant

  • Wat wil je met de site?
  • Wat is het doel?
  • Wil je informatie geven?
  • Of producten verkopen?

Past het binnen mijn kennis?

Wat staat er in een offerte

  • Wat ga je doen
  • Begroting
  • Planning en afspraken
  • Algemene voorwaarden

Bepaal je uurloon maar hou rekening met de sector. Voor culturele diensten vraag je vaak een lager uurloon dan voor een commeriecele dienst.

Van schets naar ontwerp

  • Grove schetsen
  • Hi-Fi design
  • Development
  • Design changes on the way

Het bouwproces

  • Fundering datamodel
  • Framework kiezen
  • CMS uitkiezen
  • Testen
    • HTML validator
    • Lighthouse test
  • Acceptatie omgeving opzetten
    • Development omgeving (voor mij)
    • Test server (voor mij en andere devs)
    • Acceptatie omgeving (voor de klant)
    • Productie omgeving (live voor iedereen)

Afspraken over oplevering

  • Nooit vrijdag live gaan
  • Garantie & bugs fixing
  • Betalingsmethode
    • Voorschot van 40% achteraf 60%
    • Alles achteraf
  • Factuur sturen

Maak een uren overzicht voor jezelf en eventueel voor de klant.

Altijd iets meer uren inschatten dan je nodig hebt voor marge en winst.

Service Level Agreement

Wat ga of kan je doen voor de klant na het project?

  • Hosting & e-mail
  • Vaste aantal uren per maand voor features & onderhoud
  • Tarieven:
    • Vaak lager uurtarief omdat het een passieve inkomstenbron is
    • Voor losse features en onderhoud: standaard uurtarief
    • Voor maandelijkse features en onderhoud: lager uurtarief

Bronnen