Rubric
Table of Contents
Legenda
-
✅: voldoende
-
〽️: aanvulling
-
❓: geen idee
-
❌: nog niet voldoende
Ik heb ervoor gekozen data niet met d3 te laden, maar met fetch op te vragen zodat ik het cleanen van de data server side kan doen, en het renderen van de charts client side. Performance first, toch? <3 (of ik begrijp het verkeerd en met 'loaded with d3' wordt puur het laden van de charts met d3 bedoeld haha)
Ik had verder beter wel flink meer gebruik kunnen maken van de .map.filter.reduce-trilogie zoals covered in m'n documentatie. Voor FP heb ik eigenlijk geen specifiek doeleinde voor .reduce gevonden, behalve het outputten naar de browser maar dat had een bepaalde voorwaarde waardoor ik het daarin niet toe kon passen.
- ✅ Git, is used
- ✅ The project runs without errors
- ✅ Data is loaded with d3
- ✅ There is a representation of data
Het is bij FD makkelijker om naar m'n chart te kijken dan om zelf door de gigantische dataset heen te spitten. Voor de demonstration van FP heb ik alles momenteel gerendered met Eleventy. Was ook een klus, heb het er hopelijk leuker uit laten zien dan een losse array.
- ✅ Data is rendered with d3
- ✅ Interpreting the representation is easier that interpreting the data itself
- ✅ Functional patterns are used to clean and transform data.
- ❓ Representation and use of d3 go beyond an example.
- ✅ Code is set up in a modular way and has no unexpected side effects
- ❓😱 The way the student applies subject matter is more advanced than what they were taught in class; let’s switch places
De functional patterns zijn gedocumenteerd hier in de wiki onder [data-opschonen]. Of m'n structuur easily understood is en m'n keuzes okay zijn geweest, moeten jullie zelf maar kijken :) Alles had wel nog ff extra gerefactored kunnen worden, hoe staat omschreven in m'n code comments bij het desbetreffende stuk code.
- ✅ There is substantial own code
- ✅ The student can explain the code that exists
- ✅ The student can explain some parts of their code
- ✅ The student can explain how some parts works together
- ✅ The student can explain some technical choices
- ✅ The student can explain every part of their code
- ✅ The student can explain how everything works together
- ✅ The student can explain why patterns are used instead of alternatives
- ✅ The project is structured logically
- ✅❓ The project is complex but can easily be understood
- ✅❓ Alternatives to patterns covered in class was used that were great choices
- ✅❓ 🤓 The student deeply understands functional programming and can create their own functional code flows
Zoals je ziet heb ik heel veel tijd gestoken in het schrijven van de wiki-pagina's en het itereren, de enige issue is misschien de crossover van Nederlandse taal en Engelse taal maar ik ga ervanuit dat de meeste Nederlandse developers bilingual zijn :)
Ik had het liefste nog een actor diagram getoond maar dat red ik niet qua tijd 💔
- ✅ The project is handed in on time
- ✅ The project is working
- ✅ The project is documented
- ✅ The project is on GitHub
- ✅ Code style is consistent
- ✅ Code and project are partially documented
- ✅ Code adheres to standards
- ✅ Docs cover what the project is and does
- ✅ Code quality is good and enforced
- ✅ Docs are useful and professional
- ❓ 📚 Code and docs both read like great books
Het logboek heb ik expres wat informeler gehouden omdat dat mij iets beter representeert anyways. Het client-deel was tot nu toe maar één gesprek maar hij leek het concept prima te vinden. Staat nog even op 'vraagteken' dus.
- ✅ Process is partially documented in the wiki
- ✅ Process is properly documented
- ✅ Choices are evaluated and documented
- ✅ Progress is demonstrated
- ❓ Work reflects client's needs
- 〽️ Significant progress or iterations are demonstrated
- ❓ Client is happy with the work
- 〽️ 💪 What you did this course is amazing; Teachers and client are in awe of your progress
Check livelink, compleetheid van readme --> livelink werkt, readme is compleet
- Student kan laten zien welke FP principes worden toegepast op code. --> in wiki
- Map en filter worden gebruikt. Er zijn herbruikbare functies geschreven --> map en filter zijn beide gebruikt en functies worden herbruikt
- Er wordt data asynchroon ingeladen (mag met promises) --> zowel met async await als met gewone promises
- Er is een chain van functies die data opschoont in verschillende stappen --> yes
- Complexiteit van opschonen en transformeren data beoordelen
- Ophoging: FP principes goed toegepast, uitgebreid opschonen/transf data
- Check functioneel patroon dat in de wiki gelinked/gepaste is. Snapt student hoe het beter zou kunnen? Kunnen keuzes verdedigd worden (dit is al ophoging) --> als het goed is heb ik hierboven en in de wiki en in codecomments erbij gezet wat allemaal gerefactored zou moeten worden
- Idealiter is er én cleaning én transforming te zien en een uitleg van F
- Wat heb je geleerd? Hoe meer nieuwe dingen hoe sterker --> beetje lastig als herkanser maar ik heb wel veel meer geleerd tov vorig jaar
- Eigen uitleg van d3 en geleerde features, FP principles, documentatie van update (voor understanding) en experimenten) --> heb ik als het goed is behandeld in deze wiki onder de desbetreffende pagina's. De experimenten kun je misschien eerder in m'n logboek terugvinden, maar v1 en v2 alsnog apart gecovered
- Denk terug aan readme netheid en uitgebreidheid, structuur van wiki, inhoud readme --> i tried
- Code kwaliteit: naming conventions, comments, niveau van code, consistentie, structuur, separation of concerns --> het kan nog veel beter maar heb wel stappen gemaakt hierin
