joeni | Gitar

Big addition in the thesis files

I've added a lot of new files I've been working on lately, as well as a ton of modifications to existing files. Some files have been deleted, but they were obsolete anyway.

Author: Maarten Vangeneugden
Date: Aug. 5, 2018, 10:23 p.m.
Hash: a4f6a463f4956f9ab4e463cad3d34bc7e7a98dc0
Parent: 449c0cd5e4ab16a9ba0f1f57f85814189daa8144
Modified files: docs/thesis/BlackBoard.org; docs/thesis/beveiliging.org; docs/thesis/blackboard.org; docs/thesis/client-side-scripting.org; docs/thesis/info-processen.org; docs/thesis/inplannen.org; docs/thesis/lokaalreservaties.org; docs/thesis/master.org; docs/thesis/postgres.org; docs/thesis/sources.bib; docs/thesis/toekomst.org; docs/thesis/uurrooster.org; docs/thesis/uurroosters.org; docs/thesis/verbeteringspunten_joeni.org; docs/verslagen.org → docs/thesis/verslagen.org

docs/thesis/BlackBoard.org ¶

0 additions and 11 deletions.

View changes Hide changes

De UHasselt gebruikt al jaren BlackBoard als digitaal platform voor het
uitwisselen van studiemateriaal tussen docenten en studenten.\\
** Propriëtaire software
*** Service as a software substitute (SaaSS)
** Kostelijk
<Uit goede bron heb ik kunnen vernemen dat BlackBoard de UHasselt jaarlijks
~€100.000 euro kost.>....
** Geen huisstijl mogelijk
** Onstabiel
** Slechte reputatie


docs/thesis/beveiliging.org ¶

1 addition and 1 deletion.

View changes Hide changes

Web-applicaties worden blootgesteld aan tal van mogelijke beveiligingsproblemen.
Een beetje /cracker/ kan een onbeveiligde website in weinig tijd
binnendringen.\\
Mede dankzij het gebruik van Django zijn de meeste mogelijke veiligheidslekken
gedicht. De belangrijkste onderwerpen (en gemaakte afwegingen) worden hier uitgelegd.
** Cross site scripting
Cross site scripting (XSS) laat toe om scripts te injecteren in de browsers van andere
gebruikers door bv. scripts op te slaan in de databank, die dan later worden
uitgelezen en op de computer van andere gebruikers wordt uitgevoerd.

Binnen Django wordt XSS opgelost door middel van
/[[https://docs.djangoproject.com/en/2.0/ref/templates/language/#automatic-html-escaping][automatic HTML escaping]]/; de data die gebruikers ingeven, wordt behandeld als "onveilig".
*** Orgmode
Binnen Joeni kan gebruik worden gemaakt van Orgmode-syntax om teksten van 
opmaak te voorzien, zoals vette tekst, hyperlinks, lijsten enz.

Het is technisch gezien ook mogelijk om broncode in Org te markeren, zelfs om
deze uit te laten voeren, met alle [[https://orgmode.org/org.html#Code-evaluation-security][veiligheidsrisico's]] die daaruit volgen.

Ik heb toch geopteerd om Orgmode-syntax toe te laten voor data die door
gebruikers wordt verstuurd, maar *enkel* voor personeel van de UHasselt.
Personeelsleden kunnen makkelijker aansprakelijk gehouden worden voor misbruik
van de hen aangeleverde voorrechten, en de mogelijke gevolgen van dergelijk misbruik
zullen volgens mij afdoende werken om XSS via Orgmode tegen te gaan. Moest dat
niet kloppen, dan kan Orgmode altijd gemakkelijk uitgeschakeld worden, slechts
met een tolereerbaar verlies aan opmaak binnen Joeni.

** Externe malafide programmatuur
Bij het opvragen van scripts buiten de eigen server is er steeds een risico dat
er malafide code wordt binnengehaald; men weet niet welke acties ondernomen
worden op die andere servers om kraken tegen te gaan.\\
Dit is al verscheidene keren voorgevallen <BRONNEN>, en de kern van het probleem is tot nu
toe nog altijd niet opgelost, omdat het niet kán worden opgelost: Downloaden van
ongecontroleerde scripts houdt een inherent veiligheidsrisico in.

Joeni lost dit op door simpelweg _geen_ externe scripts in te laden. Dit is
namelijk ook een reden waarom /client-side scripting/ overal vermeden wordt;
het opent een deur tot problemen waarover geen interne controle mogelijk is.


Alle software, media, /stylesheets/, bibliotheken, ... worden vanaf de server
gedraaid. 
** Clickjacking

** Cross site request forgery
Cross site request forgery (CSRF) 

** Kraken van wachtwoorden en -zinnen
*** Geen verplichte wijzigingen


docs/thesis/blackboard.org ¶

198 additions and 0 deletions.

View changes Hide changes

+	1	Blackboard, het digitale platform dat wordt aangeleverd door Blackboard Inc.,,
+	2	wordt (voornamelijk) op de UHasselt gebruikt voor het verspreiden van
+	3	lesmateriaal onder de studenten en het maken van aankondigingen betreffende het
+	4	vak of opdrachten die moeten worden ingediend.
+	5
+	6	Een groot deel van hoe Joeni gebouwd is, bestaat uit functionaliteit die
+	7	Blackboard aanbiedt, en dat is niet zonder reden. Blackboard is een slechte zaak
+	8	voor de universiteit en haar studenten, en daar zijn verschillende redenen voor.
+	9
+	10	*** Onbetrouwbaarheid
+	11	Veel Amerikaanse universiteiten hebben /vroeger/ al samengewerkt met Blackboard,
+	12	met de nadruk op vroeger. Er zijn op het internet tal van artikelen te vinden
+	13	over deze universiteiten die klagen over het stelselmatig uitvallen van
+	14	Blackboard@@latex:\cite{bb-blackout1}\cite{bb-blackout2}@@, verlies van
+	15	data@@latex:\cite{bb-dataloss}@@ en
+	16	crashes@@latex:\cite{bb-crash}@@,
+	17	Er zijn ook hier en daar pagina's opgericht door studenten die een iets
+	18	ongenuanceerdere toon aanslaan zoals een [[https://web.archive.org/web/20110719215525/http://wwwapps.ivytech.edu/phpbb/viewtopic.php?p=14937&highlight=&sid=461341d24f37a90f0f83c16fc3bedcae]["Ik haat Blackboard"-groep]], maar hierop
+	19	zal niet verder worden ingegaan.
+	20
+	21	Uit persoonlijke ervaringen weet ik zelf ook dat Blackboard soms niet
+	22	werkt naar behoren. Een voorbeeld hiervan was een opdracht voor het vak Computernetwerken,
+	23	waarin Blackboard de inzendingen weigerde omdat deze "gevaarlijk" waren, ook al
+	24	waren dit gewoon tekstbestanden met een .py-extensie. Het bestand in een
+	25	zip-bestand plaatsen werkte wel.\\
+	26	Zo nu en dan was de website op zich gewoon niet bereikbaar, en gaf het een HTTP
+	27	503-error. Na een tijdje waren deze problemen wel weg.
+	28
+	29	Enige nuance vereist ook dat deze universiteiten vaak ook veel meer van hun
+	30	digitale behoeften op de schouders van Blackboard plaatsen, en het dus ook
+	31	waarschijnlijker is dat ze in contact komen met problemen. Maar de frequentie
+	32	van deze problematiek doet vermoeden dat het zeker geen eenmalige problemen zijn.
+	33	*** Hoge kosten
+	34	Tijdens een vergadering van de Studentenraad kwam naar voren dat het contract
+	35	met Blackboard inc. de UHasselt jaarlijks meer dan €100.000 kost. Dit is geld
+	36	dat makkelijk gespendeerd kan worden aan andere zaken als voor een andere
+	37	oplossing gekozen wordt.
+	38
+	39	Als tegenargument kan natuurlijk worden aangevoerd dat dit gewoon de prijs is
+	40	die men betaalt voor dergelijke software, en dat informatici aannemen voor
+	41	interne software te schrijven minstens zo duur is. Het is echter de vraag of die
+	42	prijs opweegt tegen de punten die in dit hoofdstuk worden aangehaald.
+	43	*** Gebruiksvoorwaarden
+	44	De gebruiksvoorwaarden die Blackboard oplegt aan hun gebruikers staat geenszins
+	45	in verhouding tot wat nodig is om de goede werking van de dienst te waarborgen.
+	46	Deze voorwaarden gaan in enkele gevallen uiterst ver, gegeven enkele voorbeelden hiervan.
+	47
+	48	Het feit dat deze eisen gesteld worden is een direct gevolg van de [[Onvrije software][propriëtaire
+	49	software]] die Blackboard is: Onvrije software geeft de ontwikkelaar ervan
+	50	oneerlijke macht over de gebruikers, en Blackboard inc. heeft die macht
+	51	uitgeoefend.
+	52	**** Schending van de privacy
+	53	De studenten hebben een recht op privacy bij het uitvoeren van hun academische
+	54	verantwoordelijkheden, en dus ook bij het gebruik van de benodigde software hiervoor.
+	55
+	56	Blackboard heeft echter bedenkingen hiermee, en vereist dat hun gebruikers (en
+	57	dus ook de studenten van de UHasselt) akkoord gaan met hun privacyverklaring.@@latex:\cite{bb-privacy}@@
+	58	Hierin staan dan teksten te lezen zoals het volgende:
+	59	#+BEGIN_QUOTE
+	60	Analytics and marketing. We analyze usage information for sales and
+	61	marketing purposes and for trends about our visitors and their demographics and
+	62	how they use our websites. This analysis is necessary to further our legitimate
+	63	interest in understanding our users and how they interact with us and our
+	64	websites, improving our websites and communication
+	65	with you (including for marketing purposes).
+	66	#+END_QUOTE
+	67	Het komt erop neer dat informatie die ze inzamelen gebruikt zal worden voor
+	68	reclamedoeleinden.
+	69
+	70	Het probleem hiermee is dat studenten gewoon geen keuze hebben of ze hiermee
+	71	akkoord gaan of niet: Door niet akkoord te gaan krijgen ze geen toegang tot het
+	72	studiemateriaal van hun docenten, zijn ze niet op de hoogte van taken, ... Dit
+	73	is natuurlijk ook een gevolg van het gebruik van [[Onvrije software][onvrije software]], maar dat praat het
+	74	geenzins goed.
+	75
+	76	De UHasselt heeft een verplichting aan haar studenten om hun rechten te
+	77	beschermen als ze willen studeren, en Blackboard maakt hier misbruik van hun
+	78	positie om data van studenten te misbruiken, of ze dat nu willen of niet.
+	79	Het enige wat we hebben is een "belofte" dat de privacy serieus genomen wordt,
+	80	maar met dergelijke tegenstrijdige verklaringen is het maar de vraag hoe
+	81	betrouwbaar dat is.
+	82
+	83	Tot slot is het verwerken van deze gegevens mogelijk in strijd met de Algemene
+	84	Verordering Gegevensbescherming; het verwerken van deze gegevens voor
+	85	marketingdoeleinden mag enkel met
+	86	expliciete toestemming van de gebruiker.@@latex:\cite{eu-gdpr}@@
+	87	Maar opnieuw: de gebruiker heeft hier
+	88	als student (of docent) niet echt een keus of hij/zij akkoord gaat of niet. Het is maar
+	89	de vraag wat een toestemming die op dergelijke manier verkregen wordt nu
+	90	eigenlijk waard is.
+	91
+	92	**** Kopieerrechten
+	93	Auteurs van creatieve werken zouden zelf moeten kunnen bepalen wanneer hun werken
+	94	(publiek domein niet meegerekend) gebruikt mogen worden voor commerciële
+	95	doeleinden. Blackboard stelt echter in hun gebruiksvoorwaarden:@@latex:\cite{bb-tos}@@
+	96	#+BEGIN_QUOTE
+	97	By submitting, posting or displaying Content on or through the Products,
+	98	you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense)
+	99	to use, host, store, copy, reproduce, process, adapt, modify, publish, transmit,
+	100	create derivative works from, communicate, display, and/or distribute such Content
+	101	in any and all media or distribution methods (now known or later developed) as
+	102	part of providing any of the Products. You agree that this license includes the
+	103	right for Blackboard to provide, promote, and improve the Products and to make
+	104	Content submitted to or through the Products available to other institutions or
+	105	individuals as part of providing the Products (including after termination of
+	106	your use of the Products) and in accordance with your privacy settings. You
+	107	represent and warrant that you have all the rights, power and authority
+	108	necessary to grant the rights granted herein to any Content that you submit.
+	109
+	110	../..
+	111
+	112	Blackboard may exercise the rights to your Content granted under these Terms
+	113	without liability for payment of any guild fees, residuals, payments, fees, or
+	114	royalties payable under any collective bargaining agreement, licensing
+	115	arrangement or otherwise.
+	116	#+END_QUOTE
+	117	Er is geen reden voor Blackboard om te eisen van studenten (en andere gebruikers
+	118	zoals docenten) dat Blackboard inc. hun werken voor praktisch alles mag
+	119	gebruiken, zonder enige vorm van compensatie of naamsvermelding. Opnieuw maken ze hiermee
+	120	misbruik van hun positie als digitaal platform van universiteiten om eisen te
+	121	stellen aan gebruikers waar ze normaal vrijwel nooit mee akkoord zouden gaan.
+	122
+	123	*** Onvrije software
+	124	De software die Blackboard gebruikt, is propriëtaire software, waarvan de
+	125	werking niet bekend is, in die zin dat de UHasselt geen inzage heeft in hoe hun
+	126	data wordt afgehandeld. Gegeven [[Gebruiksvoorwaarden][de gebruiksvoorwaarden]] doet dit vermoeden dat er
+	127	ook activiteiten gebeuren die niet noodzakelijk zijn, zoals het gebruik van de
+	128	data voor marketing en profilering van studenten.
+	129
+	130	De propriëtaire software maakt dit mogelijk; door de broncode verborgen te
+	131	houden en fundamentele rechten te ontzeggen,
+	132	kan er geen controle plaatsvinden op wat er nu echt gebeurt met de data
+	133	van onze studenten. Sterker: Het gebrek aan controle (en de positie die
+	134	Blackboard heeft binnen de universiteit), samen met de wetenschap dat de
+	135	gebruikers hier weinig verweer tegen kunnen bieden, zet aan tot misbruik van die
+	136	machtspositie, en het implementeren van functionaliteit die de gebruikers nefast
+	137	behandeld. Dit wordt ook wel /malware/ genoemd.
+	138
+	139	We kunnen zelf ook de software niet aanpassen naar de behoeften van de UHasselt,
+	140	ook hiervoor zijn we afhankelijk van Blackboard inc.
+	141
+	142	Kortom: Doordat Blackboard geen vrije software is, heeft de universiteit geen
+	143	controle over de software.
+	144
+	145	Joeni zou voor de student op dezelfde manier als Blackboard bereikt worden, maar
+	146	de broncode van Joeni is wél vrij in te zien (dit is namelijk ook één van de
+	147	veiligheidsgaranties). De studenten kunnen er sowieso redelijkerwijs op vertrouwen dat de
+	148	universiteit hun rechten ter harte neemt, maar met vrije software hebben ze ook
+	149	een garantie hiervoor.
+	150	*** Toledo & Minerva/Ufora
+	151	De Universiteit Gent[fn:minerva], Vrije Universiteit Brussel en Katholieke Universiteit Leuven maken geen gebruik van
+	152	externe bedrijven voor hun digitale behoeften. In plaats daarvan gebruiken zij
+	153	software "van het huis"; de software is ontwikkeld voor en door de universiteit
+	154	zelf. Het toont aan dat een universitair digitaal platform bouwen mogelijk is,
+	155	en dat het academische standaarden kan aanhouden. Er is geen nood om te
+	156	vertrouwen op een bedrijf zoals Blackboard, en genoegen te nemen met een
+	157	"algemene" oplossing.
+	158
+	159	[fn:minerva] In het afgelopen academiejaar heeft de UGent een
+	160	aanbesteding uitgegeven voor bedrijven om een nieuwe Minerva te bouwen. Dit
+	161	nieuwe programma zal Ufora heten, en (het ondertussen vijftien jaar oude)
+	162	Minerva gaandeweg vervangen.@@latex:\cite{ufora}@@ Alhoewel
+	163	zij dus ook overschakelen op een extern bedrijf, kiezen zij hiermee nog steeds
+	164	voor een "persoonlijke" oplossing, en niet voor iets wat niet specifiek voor hen gemaakt is.
+	165
+	166	Natuurlijk zijn deze universiteiten aanzienlijk groter dan de UHasselt wat
+	167	betreft het aantal studenten. De Universiteit Antwerpen
+	168	gebruikt ook Blackboard als digitaal platform, en telt zelf ook al 20.000 studenten.
+	169	Maar de UHasselt heeft eerder zelf ook al de
+	170	ambitie geuit om te blijven groeien@@latex:\cite{uhasselt-groeit}@@, en voor een
+	171	langetermijnoplossing is een oplossing op maat zeker geen overbodige luxe.
+	172	*** Informatica binnen de UHasselt
+	173	Binnen de faculteit Wetenschappen op de UHasselt zijn er niet veel
+	174	masteropleidingen. Maar buiten de Master of Statistics wordt er wel fel ingezet
+	175	op de Master in de Informatica, met maar lieft zes (!) mogelijke
+	176	specialisatieprofielen@@latex:\cite{opleiding-informatica}@@,
+	177	wat voor een universiteit van dergelijke grootte best opvallend te noemen is.\\
+	178	Het zou een mooie troef zijn voor de (master)opleiding als de UHasselt kan tonen
+	179	dat ze genoeg vertrouwen hebben in hun eigen kunnen, en deze kennis ook inzetten
+	180	voor het onderhoud van hun eigen informatica. Vertrouwen op een hoop externe
+	181	bedrijven voor de interne IT doet dat vertrouwen niet uitstralen.
+	182
+	183	Dit is evenwel niet zozeer een punt tégen Blackboard, maar wel een punt om te
+	184	ijveren om met het ALIPA-project nu ook in te zetten op een goede oplossing van
+	185	eigen makelij.
+	186	*** Reden(en) tot stopzetting
+	187	In de studentenraad is ter ore gekomen dat de integratie met Blackboard, ondanks
+	188	bovenstaande punten, verder wordt gezet middels een app die zou integreren met Blackboard.
+	189
+	190	Misschien is het beter om de samenwerking echter stop te zetten. Voor ALIPA zou
+	191	het makkelijker zijn om de vernieuwing door te laten gaan als er controle is
+	192	over zo'n cruciaal onderdeel van de universiteit.
+	193
+	194	Met Joeni is er een voorstel dat laat zien hoe de functies die nu door
+	195	Blackboard worden aangevoerd, geïntegreerd kunnen worden in een centrale
+	196	oplossing voor de studenten. Het is niet zo moeilijk als op het eerste zicht zou
+	197	lijken, en veegt direct alle gegeven problemen van de baan.
+	198

docs/thesis/client-side-scripting.org ¶

216 additions and 216 deletions.

View changes Hide changes

Ingewijden zijn bekend met het feit dat JavaScript een Turing-complete
programmeertaal is; je kunt er dus daadwerkelijk programma's mee schrijven.
Een prominent voorbeeld hiervan is Google met haar Google Docs, Sheets,
Presentations, GMail, ...

Het valt dan natuurlijk op dat binnen Joeni *geen enkele lijn JavaScript
geschreven is*. En dat is ook expres gedaan.
Dat klinkt misschien nogal contra-intuïtief; een volledig programma, dat
hoofdzakelijk gebruikt zal worden via de browser, dat client-side scripting
expres aan zijn neus voorbij laat gaan.

Hier zijn meerdere redenen voor. Eén van de voornaamste redenen (en eentje die
Google, Facebook, ... allemaal klaarblijkelijk vergeten zijn) is dat een
grondregel van /web development/ is dat je er niet van mag uitgaan dat de
gebruiker JavaScript ondersteunt.

*Client-side scripting (Css* (niet te verwarren met Cascading Style Sheets, CSS))
*mag enkel een strikt cosmetisch effect hebben op
een website.* De functionaliteit gaat namelijk compleet verloren als de
gebruiker geen ondersteuning biedt.

Alhoewel het in de praktijk steeds neerkomt op "JavaScript (JS) dient vermeden te
worden op het web", ga ik enkel spreken over "Client side scripting" (Css),
omdat veel van de problemen die zich met JS zouden voordoen, zich eveneens
zouden voordoen bij eender welke andere taal (Python, Clojure, ...),
als die voor Css gebruikt zou worden. JS is sinds [[http://es6-features.org/][ES6]] een betere taal geworden,
maar de "kwaliteit" van een taal is volledig irrelevant in deze discussie. Het
bespreken van de faciliteiten die JS als programmeertaal biedt wordt in dit
hoofdstuk dus achterwege gelaten.

Er wordt hier ook enkel gefocust op het gebruik van Css om bepaalde
functionaliteit te laten werken. Css die enkel een cosmetisch effect heeft is
niet het onderwerp van dit stuk, maar wordt eveneens vermeden om aan te tonen
dat een bruikbare web-applicatie ook mooi kan zijn met enkel HTML en CSS.

** Verschillende versies
Alles wat netwerkgerelateerd is, moet zich houden aan vooraf opgelegde
standaarden om correct te kunnen communiceren, en met het WWW is dat niet
anders.

Dit geeft ook een reden om geen Css te gebruiken; op dit moment moet ik
rekening houden met

- De standaard van HTML(5) en welke tags ondersteund worden
- De standaard van CSS(3) en de ondersteunde /properties/ binnen browsers

Dit op zich is al een hele klus, en vereist *continu onderhoud van de software*.

Stel dat men geen website ontwerpt, en /native software/ ontwikkelt, dan hoeft
men enkel rekening te houden met de syntax van de programmeertaal; als het
compileert kan het bij wijze van spreken gebruikt worden.[fn::In de praktijk is het niet zo voor de hand liggend, maar om het punt te maken volstaat dit.]

Met Css moet men rekening houden met welke onderdelen van de gebruikte
programmeertaal door de browsers wordt ondersteund, en dat is van vitaal belang,
want als het script niet ondersteund wordt, wordt het simpelweg niet uitgevoerd,
met als gevolg dat de website aan functionaliteit moet inboeten.

Als dit bij HTML of CSS gebeurt (bv. gebruik van [[https://developer.mozilla.org/en-US/docs/Web/HTML/Element/marquee][<marquee>]]), dan kan de browser
nog terugvallen op een standaardwaarde. Dit is ook mogelijk, omdat geen van
beide een programmeertaal is; men kán onderdelen vervangen zonder een al te
groot risico te lopen om de site kapot te maken.

Een goed voorbeeld hiervan is het ~<tel>~-element, dat wordt gebruikt om een
telefoonnummer aan te duiden op een webpagina. Op mobiele browsers wordt een
klik hierop behandeld als een telefoongesprek. Op (oudere) desktopbrowsers wordt
dit als gewone tekst weergegeven.

** Turing-compleetheid
De aantrekkingskracht van Css schuilt in de [[https://nl.wikipedia.org/wiki/Turingvolledigheid][Turing-compleetheid]]. Dit maakt het tot een
programmeertaal waarin elk mogelijk computerprogramma geprogrammeerd kan worden.

De grote máár in deze kracht, is dat dat ook een hoop verantwoordelijkheid met
zich meebrengt. Er kunnen fouten in de code sluipen, die de hele website kunnen
doen vastlopen.

JavaScript heeft dan ook nog de ongelukkige eigenschap dat het een enorm
[[https://en.wikipedia.org/wiki/Strong_and_weak_typing][zwak getypeerde programmeertaal]] is; de taal doet in de achtergrond stille
conversies tussen verschillende types, en geeft liever foute resultaten terug
dan de programmeur te vertellen dat er een fout in de code zit.

Deze punten gelden natuurlijk ook voor de /server-side/, maar dit is (in
tegenstelling tot Css) absoluut onvermijdelijk om een dergelijke website te
creëren.
Daarnaast zijn er ook een hoop voordelen die men niet heeft bij Css:

- Vrije keuze van programmeertaal (en mogelijkheid om te linken met andere
  software)
- Zekerheid dat, als de software werkt op de ene /client/, die ook voor de
  andere /client/ werkt (zie [[Verschillende versies]])

HTML en CSS zijn geen "volwaardige programmeertalen". HTML is een opmaaktaal,
men beschrijft er dus mee hoe bepaalde onderdelen van de website moeten worden
voorgesteld; als een hyperlink, een paragraaf, ...
CSS laat toe om de stijl van deze opmaak te definiëren, hoe moet een hyperlink
uitzien, ...

Een fout hierin heeft hoogstens een esthetisch vervelend effect tot gevolg; veel
browsers negeren fouten, en vervangen deze door /fallbacks/. Dit is niet
mogelijk met een programmeertaal; een fout is een fout, en computers zijn niet
in staat om een fout programma zelf te repareren.

** Onbeschikbaarheid
Er zijn talloze manieren waarop de aangereikte code niet beschikbaar kan zijn
voor de gebruiker, waardoor een website die afhangt van Css plots zonder
waarschuwing niet meer werkzaam is. Een wilde greep uit de mogelijkheden:

- De gebruiker heeft een zwakke computer
- De computer heeft een slechte verbinding
- De gebruiker surft via de GSM (een zwakke computer met een slechte verbinding)
- De gebruiker heeft [[https://noscript.net][NoScript]], [[https://www.gnu.org/software/librejs/][GNU LibreJS]], of een andere extensie die Css blokkeert
- De verbinding wordt onderbroken tijdens het inladen, en de pagina blokkeert
  terwijl het tevergeefs wacht op de rest van het script
- De browser van de gebruiker ondersteunt simpelweg geen Css
- De browser van de gebruiker ondersteunt niet de Css-implementatie die op de
  website gebruikt wordt (zie [[Verschillende versies]])
- De website laadt Css in van een externe website, maar er is een fout in het
  certificaat, en de browser weigert om de verbinding op te zetten
- ...

Er hoeft maar één (en slechts één) van deze mogelijkheden op te treden, en *de
volledige website is per direct compleet onbruikbaar*.

Voor elk van deze mogelijkheden zou met Css een controle moeten worden
ingebouwd, en dan weer voor elke mogelijkheid een oplossing bedacht (want "Het
werkt niet en dat is de schuld van de gebruiker" is geen oplossing).

Daarentegen, wat als er server-side een fout optreedt? \\
Veel webframeworks hebben ingebouwde /debugging tools/ die bij fouten direct de
programmeur wijzen op de fout. Django is hier een goed voorbeeld van.

Daarnaast biedt de betere webserver ook ingebouwde oplossingen om vaak
voorkomende fouten af te handelen (zoals een HTTP 404). In dat geval kan er
gemakkelijk een e-mail naar de ontwikkelaar gestuurd worden, of kan een log
aangemaakt worden. En dit is vaak allemaal /ingebouwd/.

** Uitgesteld resultaat
Bestanden over het WWW worden quasi altijd verzonden via [[https://nl.wikipedia.org/wiki/Hypertext_Transfer_Protocol][HTTP]]([[https://nl.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure][S]]), en de browser
is daarna verantwoordelijk voor het in elkaar steken van alle ontvangen
onderdelen.

Het handige hieraan, is dat elke browser zelf kan bepalen hoe, en in welke volgorde dit
moet gebeuren, al dan niet in functie van bepaalde instellingen die de gebruiker
zelf kan aanpassen (bv. geen afbeeldingen laden via 4G).

Css interfereert op haast elk mogelijk niveau met deze werkwijze. Net omdat het
niet op voorhand geweten is wat er zal worden aangepast, of wanneer de code
ingeladen moet worden, is een browser verplicht om vanaf het eerste moment dat
een script gedetecteerd wordt (bv. via de ~<script></script>~-tags), direct de
code te evalueren en uit te voeren, ongeacht hoe lang het duurt of hoe zwaar het is.

Css breekt ook met het gebruikelijke mantra dat de browser/gebruiker bepaalt hoe
en wat wordt ingeladen.
Vaak betekent dit ook dat de code geëvalueerd moet worden, op dat exacte moment,
vooraleer de rest van de pagina getoond kan worden. \\
Dit is minder een probleem als Css gebruikt wordt voor het enige waarvoor het
zou gebruikt moeten worden (cosmetische elementen), omdat praktisch alle code dan expres
op het einde van het HTML-document kan worden ingeladen. De website is dan al
bruikbaar vooraleer de code ingeladen moet worden. \\
Een groeiend aantal gebruikers blokkeert ook expres Css tijdens het surfen op
het web, omdat de snelheidswinsten en sterk verhoogde privacy een waardige
afweging is voor een ietwat minder cosmetisch aangeklede website. Met andere
woorden; zij stellen het resultaat uit voor onbepaalde duur.

Dit geeft vanzelfsprekend ook problemen als de code niet geoptimaliseerd is, en
daar elke browser de aangereikte Css op een andere manier kan evalueren, is het
onbegonnen werk om voor alle mogelijke implementaties handige optimalisaties
door te voeren. Men beperkt zich natuurlijk meestal tot de populairste
implementaties ([[https://en.wikipedia.org/wiki/WebKit][WebKit]] en [[https://en.wikipedia.org/wiki/Gecko_(software)][Gecko]]).

_Maar je hoeft vanzelfsprekend niet te optimaliseren, als er geen code is om te optimaliseren._

Je zou kunnen zeggen dat deze redenering ook opgaat voor Joeni zelf, wat van
Python gebruik maakt. Maar het gebruikte framework ondersteunt het
[[https://docs.djangoproject.com/en/2.0/topics/cache/][cachen van pagina's]]. Dus eerder geëvalueerde code zal al op voorhand beschikbaar
zijn. Daarbij komt dat de snelheid van een server naar wens kan worden vergroot,
terwijl je bij de gebruiker er van moet uitgaan dat zijn/haar toestel traag is.
De code van de server hoeft ook slechts voor één platform geoptimaliseerd te
worden, dat van de server.

Uiteindelijk is het resultaat van (foutief) Css-gebruik 
sowieso: *Een traag werkende website.*

** Verlies van betekenis
Een bepaalde /tag/ in HTML draagt een bepaalde betekenis. ~<a />~ betekent dat dit
een hyperlink is, ~<body />~ betekent dat wat volgt getoond moet worden als de
'inhoud' van de pagina, ~<p />~ duidt op een paragraaf, ...

Deze betekenis wordt vaak door de browser ten volle benut; Alle links kunnen makkelijk
op voorhand verzameld worden (i.e. Alles wat tussen ~<a />~ staat), wat tussen
~<head />~ staat wordt niet getoond, ...

*Betekenis opent deuren voor het impliciet infereren van informatie.* Dit is de
reden waarom de tags in HTML (en vooral sinds HTML5) een aanduiding zijn voor
wat de ingesloten data /betekent/; ~<article />~ is een artikel en kan dus los
weergegeven worden van de rest van de pagina, ~<del />~ is iets dat niet
meer relevant is, maar waarschijnlijk toch wel weergegeven moet worden. ~<ol />~
is een geordende lijst, dus de volgorde van de data is van belang, in
tegenstelling tot ~<ul />~. Er zijn ontelbare voorbeelden te vinden.

Deze betekenis gaat volledig verloren als onderdelen van de website met Css
worden "nagemaakt". ~<div onclick="hyperlink" />~ zal waarschijnlijk wel
doorlinken naar een website, maar waar dat je in bv. FireFox met een
middelmuisklik een ~<a />~ in een nieuw tabblad kunt openen, zal dit niet werken
met Css.

** Conclusie
Het moge duidelijk zijn dat het gebruik van Css om zogenaamde /web apps/ te
maken, fundamenteel een slecht idee is, dat meer problemen voortbrengt dan het
oplost. Alle problemen die sommige websites proberen op te lossen met Css, zijn
makkelijker op te lossen met slechts HTML en CSS (Cascading Style Sheets), en
Client side scripting maakt soms de problemen zelfs erger.

En zelfs al zouden alle bovenstaande punten onwaar zijn, dan nog is Joeni
het bewijs dat Css geen vereiste is om werkende software te schrijven, die
hoofdzakelijk via het WWW beschikbaar wordt gesteld.

 Ingewijden zijn bekend met het feit dat JavaScript een Turing-complete
 programmeertaal is; je kunt er dus daadwerkelijk programma's mee schrijven.
 Een prominent voorbeeld hiervan is Google met haar Google Docs, Sheets,
 Presentations, GMail, ...

 Het valt dan natuurlijk op dat binnen Joeni *geen enkele lijn JavaScript
 geschreven is*. En dat is ook expres gedaan.
 Dat klinkt misschien nogal contra-intuïtief; een volledig programma, dat
 hoofdzakelijk gebruikt zal worden via de browser, dat client-side scripting
 expres aan zijn neus voorbij laat gaan.

 Hier zijn meerdere redenen voor. Eén van de voornaamste redenen (en eentje die
 Google, Facebook, ... allemaal klaarblijkelijk vergeten zijn) is dat een
 grondregel van /web development/ is dat je er niet van mag uitgaan dat de
 gebruiker JavaScript ondersteunt.

 *Client-side scripting (Css* (niet te verwarren met Cascading Style Sheets, CSS))
 *mag enkel een strikt cosmetisch effect hebben op
 een website.* De functionaliteit gaat namelijk compleet verloren als de
 gebruiker geen ondersteuning biedt.

 Alhoewel het in de praktijk steeds neerkomt op "JavaScript (JS) dient vermeden te
 worden op het web", ga ik enkel spreken over "Client side scripting" (Css),
 omdat veel van de problemen die zich met JS zouden voordoen, zich eveneens
 zouden voordoen bij eender welke andere taal (Python, Clojure, ...),
 als die voor Css gebruikt zou worden. JS is sinds [[http://es6-features.org/][ES6]] een betere taal geworden,
 maar de "kwaliteit" van een taal is volledig irrelevant in deze discussie. Het
 bespreken van de faciliteiten die JS als programmeertaal biedt wordt in dit
 hoofdstuk dus achterwege gelaten.

 Er wordt hier ook enkel gefocust op het gebruik van Css om bepaalde
 functionaliteit te laten werken. Css die enkel een cosmetisch effect heeft is
 niet het onderwerp van dit stuk, maar wordt eveneens vermeden om aan te tonen
 dat een bruikbare web-applicatie ook mooi kan zijn met enkel HTML en CSS.

*** Verschillende versies
 Alles wat netwerkgerelateerd is, moet zich houden aan vooraf opgelegde
 standaarden om correct te kunnen communiceren, en met het WWW is dat niet
 anders.

 Dit geeft ook een reden om geen Css te gebruiken; op dit moment moet ik
 rekening houden met

 - De standaard van HTML(5) en welke tags ondersteund worden
 - De standaard van CSS(3) en de ondersteunde /properties/ binnen browsers

 Dit op zich is al een hele klus, en vereist *continu onderhoud van de software*.

 Stel dat men geen website ontwerpt, en /native software/ ontwikkelt, dan hoeft
 men enkel rekening te houden met de syntax van de programmeertaal; als het
 compileert kan het bij wijze van spreken gebruikt worden.[fn::In de praktijk is het niet zo voor de hand liggend, maar om het punt te maken volstaat dit.]

 Met Css moet men rekening houden met welke onderdelen van de gebruikte
 programmeertaal door de browsers wordt ondersteund, en dat is van vitaal belang,
 want als het script niet ondersteund wordt, wordt het simpelweg niet uitgevoerd,
 met als gevolg dat de website aan functionaliteit moet inboeten.

 Als dit bij HTML of CSS gebeurt (bv. gebruik van [[https://developer.mozilla.org/en-US/docs/Web/HTML/Element/marquee][<marquee>]]), dan kan de browser
 nog terugvallen op een standaardwaarde. Dit is ook mogelijk, omdat geen van
 beide een programmeertaal is; men kán onderdelen vervangen zonder een al te
 groot risico te lopen om de site kapot te maken.

 Een goed voorbeeld hiervan is het ~<tel>~-element, dat wordt gebruikt om een
 telefoonnummer aan te duiden op een webpagina. Op mobiele browsers wordt een
 klik hierop behandeld als een telefoongesprek. Op (oudere) desktopbrowsers wordt
 dit als gewone tekst weergegeven.

*** Turing-compleetheid
 De aantrekkingskracht van Css schuilt in de [[https://nl.wikipedia.org/wiki/Turingvolledigheid][Turing-compleetheid]]. Dit maakt het tot een
 programmeertaal waarin elk mogelijk computerprogramma geprogrammeerd kan worden.

 De grote máár in deze kracht, is dat dat ook een hoop verantwoordelijkheid met
 zich meebrengt. Er kunnen fouten in de code sluipen, die de hele website kunnen
 doen vastlopen.

 JavaScript heeft dan ook nog de ongelukkige eigenschap dat het een enorm
 [[https://en.wikipedia.org/wiki/Strong_and_weak_typing][zwak getypeerde programmeertaal]] is; de taal doet in de achtergrond stille
 conversies tussen verschillende types, en geeft liever foute resultaten terug
 dan de programmeur te vertellen dat er een fout in de code zit.

 Deze punten gelden natuurlijk ook voor de /server-side/, maar dit is (in
 tegenstelling tot Css) absoluut onvermijdelijk om een dergelijke website te
 creëren.
 Daarnaast zijn er ook een hoop voordelen die men niet heeft bij Css:

 - Vrije keuze van programmeertaal (en mogelijkheid om te linken met andere
   software)
 - Zekerheid dat, als de software werkt op de ene /client/, die ook voor de
   andere /client/ werkt (zie [[Verschillende versies][Verschillende versies]]).

 HTML en CSS zijn geen "volwaardige programmeertalen". HTML is een opmaaktaal,
 men beschrijft er dus mee hoe bepaalde onderdelen van de website moeten worden
 voorgesteld; als een hyperlink, een paragraaf, ...
 CSS laat toe om de stijl van deze opmaak te definiëren, hoe moet een hyperlink
 uitzien, ...

 Een fout hierin heeft hoogstens een esthetisch vervelend effect tot gevolg; veel
 browsers negeren fouten, en vervangen deze door /fallbacks/. Dit is niet
 mogelijk met een programmeertaal; een fout is een fout, en computers zijn niet
 in staat om een fout programma zelf te repareren.

*** Onbeschikbaarheid
 Er zijn talloze manieren waarop de aangereikte code niet beschikbaar kan zijn
 voor de gebruiker, waardoor een website die afhangt van Css plots zonder
 waarschuwing niet meer werkzaam is. Een wilde greep uit de mogelijkheden:

 - De gebruiker heeft een zwakke computer
 - De computer heeft een slechte verbinding
 - De gebruiker surft via de GSM (een zwakke computer met een slechte verbinding)
 - De gebruiker heeft [[https://noscript.net][NoScript]], [[https://www.gnu.org/software/librejs/][GNU LibreJS,]] of een andere extensie die Css blokkeert
 - De verbinding wordt onderbroken tijdens het inladen, en de pagina blokkeert
   terwijl het tevergeefs wacht op de rest van het script
 - De browser van de gebruiker ondersteunt simpelweg geen Css
 - De browser van de gebruiker ondersteunt niet de Css-implementatie die op de
   website gebruikt wordt (zie [[Verschillende versies]])
 - De website laadt Css in van een externe website, maar er is een fout in het
   certificaat, en de browser weigert om de verbinding op te zetten
 - ...

 Er hoeft maar één (en slechts één) van deze mogelijkheden op te treden, en *de
 volledige website is per direct compleet onbruikbaar*.

 Voor elk van deze mogelijkheden zou met Css een controle moeten worden
 ingebouwd, en dan weer voor elke mogelijkheid een oplossing bedacht (want "Het
 werkt niet en dat is de schuld van de gebruiker" is geen oplossing).

 Daarentegen, wat als er server-side een fout optreedt? \\
 Veel webframeworks hebben ingebouwde /debugging tools/ die bij fouten direct de
 programmeur wijzen op de fout. Django is hier een goed voorbeeld van.

 Daarnaast biedt de betere webserver ook ingebouwde oplossingen om vaak
 voorkomende fouten af te handelen (zoals een HTTP 404). In dat geval kan er
 gemakkelijk een e-mail naar de ontwikkelaar gestuurd worden, of kan een log
 aangemaakt worden. En dit is vaak allemaal /ingebouwd/.

*** Uitgesteld resultaat
 Bestanden over het WWW worden quasi altijd verzonden via [[https://nl.wikipedia.org/wiki/Hypertext_Transfer_Protocol][HTTP]]([[https://nl.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure][S]]), en de browser
 is daarna verantwoordelijk voor het in elkaar steken van alle ontvangen
 onderdelen.

 Het handige hieraan, is dat elke browser zelf kan bepalen hoe, en in welke volgorde dit
 moet gebeuren, al dan niet in functie van bepaalde instellingen die de gebruiker
 zelf kan aanpassen (bv. geen afbeeldingen laden via 4G).

 Css interfereert op haast elk mogelijk niveau met deze werkwijze. Net omdat het
 niet op voorhand geweten is wat er zal worden aangepast, of wanneer de code
 ingeladen moet worden, is een browser verplicht om vanaf het eerste moment dat
 een script gedetecteerd wordt (bv. via de ~<script></script>~-tags), direct de
 code te evalueren en uit te voeren, ongeacht hoe lang het duurt of hoe zwaar het is.

 Css breekt ook met het gebruikelijke mantra dat de browser/gebruiker bepaalt hoe
 en wat wordt ingeladen.
 Vaak betekent dit ook dat de code geëvalueerd moet worden, op dat exacte moment,
 vooraleer de rest van de pagina getoond kan worden. \\
 Dit is minder een probleem als Css gebruikt wordt voor het enige waarvoor het
 zou gebruikt moeten worden (cosmetische elementen), omdat praktisch alle code dan expres
 op het einde van het HTML-document kan worden ingeladen. De website is dan al
 bruikbaar vooraleer de code ingeladen moet worden. \\
 Een groeiend aantal gebruikers blokkeert ook expres Css tijdens het surfen op
 het web, omdat de snelheidswinsten en sterk verhoogde privacy een waardige
 afweging is voor een ietwat minder cosmetisch aangeklede website. Met andere
 woorden; zij stellen het resultaat uit voor onbepaalde duur.

 Dit geeft vanzelfsprekend ook problemen als de code niet geoptimaliseerd is, en
 daar elke browser de aangereikte Css op een andere manier kan evalueren, is het
 onbegonnen werk om voor alle mogelijke implementaties handige optimalisaties
 door te voeren. Men beperkt zich natuurlijk meestal tot de populairste
 implementaties ([[https://en.wikipedia.org/wiki/WebKit][WebKit]] en [[https://en.wikipedia.org/wiki/Gecko_(software)][Gecko]]).

 _Maar je hoeft vanzelfsprekend niet te optimaliseren, als er geen code is om te optimaliseren._

 Je zou kunnen zeggen dat deze redenering ook opgaat voor Joeni zelf, wat van
 Python gebruik maakt. Maar het gebruikte framework ondersteunt het
 [[https://docs.djangoproject.com/en/2.0/topics/cache/][cachen van pagina's]]. Dus eerder geëvalueerde code zal al op voorhand beschikbaar
 zijn. Daarbij komt dat de snelheid van een server naar wens kan worden vergroot,
 terwijl je bij de gebruiker er van moet uitgaan dat zijn/haar toestel traag is.
 De code van de server hoeft ook slechts voor één platform geoptimaliseerd te
 worden, dat van de server.

 Uiteindelijk is het resultaat van (foutief) Css-gebruik 
 sowieso: *Een traag werkende website.*

*** Verlies van betekenis
 Een bepaalde /tag/ in HTML draagt een bepaalde betekenis. ~<a />~ betekent dat dit
 een hyperlink is, ~<body />~ betekent dat wat volgt getoond moet worden als de
 'inhoud' van de pagina, ~<p />~ duidt op een paragraaf, ...

 Deze betekenis wordt vaak door de browser ten volle benut; Alle links kunnen makkelijk
 op voorhand verzameld worden (i.e. Alles wat tussen ~<a />~ staat), wat tussen
 ~<head />~ staat wordt niet getoond, ...

 *Betekenis opent deuren voor het impliciet infereren van informatie.* Dit is de
 reden waarom de tags in HTML (en vooral sinds HTML5) een aanduiding zijn voor
 wat de ingesloten data /betekent/; ~<article />~ is een artikel en kan dus los
 weergegeven worden van de rest van de pagina, ~<del />~ is iets dat niet
 meer relevant is, maar waarschijnlijk toch wel weergegeven moet worden. ~<ol />~
 is een geordende lijst, dus de volgorde van de data is van belang, in
 tegenstelling tot ~<ul />~. Er zijn ontelbare voorbeelden te vinden.

 Deze betekenis gaat volledig verloren als onderdelen van de website met Css
 worden "nagemaakt". ~<div onclick="hyperlink" />~ zal waarschijnlijk wel
 doorlinken naar een website, maar waar dat je in bv. FireFox met een
 middelmuisklik een ~<a />~ in een nieuw tabblad kunt openen, zal dit niet werken
 met Css.

*** Conclusie
 Het moge duidelijk zijn dat het gebruik van Css om zogenaamde /web apps/ te
 maken, fundamenteel een slecht idee is, dat meer problemen voortbrengt dan het
 oplost. Alle problemen die sommige websites proberen op te lossen met Css, zijn
 makkelijker op te lossen met slechts HTML en CSS (Cascading Style Sheets), en
 Client side scripting maakt soms de problemen zelfs erger.

 En zelfs al zouden alle bovenstaande punten onwaar zijn, dan nog is Joeni
 het bewijs dat Css geen vereiste is om werkende software te schrijven, die
 hoofdzakelijk via het WWW beschikbaar wordt gesteld.


docs/thesis/info-processen.org ¶

15 additions and 0 deletions.

View changes Hide changes

+	1	Een ander prominent deel van deze bachelorproef gaat over het verbeteren van
+	2	bestaande informatieprocessen.
+	3
+	4	*** Reservatie lokalen
+	5
+	6
+	7	*** COMMENT Studiegids
+	8	Op dit moment wordt de studiegids manueel opgebouwd, waarbij
+	9	docenten/hoogleraren moeten indienen welke voorkennis vereist is, hoe het vak
+	10	gequoteerd wordt, of er een tweede kans is, ...
+	11
+	12	Dit moet ook worden goedgekeurd, waardoor wijzigingen een nogal omslachtige
+	13	procedure volgen. Daarbij lijken de pagina's in de studiegids nogal een andere
+	14	stijl te gebruiken dan de omvattende pagina.
+	15

docs/thesis/inplannen.org ¶

1 addition and 1 deletion.

View changes Hide changes

Naast het reserveren van lokalen, is er ook het werk van inplannen van de uren
van de vakken zelf.

De manieren verschillen voornamelijk per faculteit. Het volledige verslag is te vinden in
[[APPENDIX A - ...]].


De manier van inplannen verschilt bij de richting Informatica enigzins van die
van de andere richtingen binnen de faculteit Wetenschappen: Vanaf het derde
bachelorjaar worden er enkel nog hoorcolleges meer ingepland.

De oorzaak hiervan is het grote aantal specialisaties die de masteropleiding
heeft. (De andere richtingen hebben enkel een bachelorgedeelte) Voor deze vakken
meer dan enkel de hoorcolleges inplannen is onmogelijk, omdat anders er
overlappingen onstaan binnen modeltrajecten.

*** Professoren
De agenda's van de professoren worden naar voren geschoven als het primaire probleem tijdens
het opstellen van een planning: Ze zijn druk bezet, en hun afspraken zijn
moeilijk te verplaatsen.\\
Om hieraan tegemoet te komen, wordt vaak de planning van het vorige jaar als een
sjabloon genomen. Meestal komt de planning nog voldoende overeen met de vorige
versie (zeker als er geen modeltrajectwijzigingen plaatsvonden).

*** Sjablonen
Om het inplannen zo makkelijk mogelijk te laten verlopen, wordt er steeds
vertrokken van de planning van het vorige academiejaar als sjabloon. 
Als er geen veranderingen zijn, dan worden er geen wijzigingen aangebracht.

Indien er toch aanpassingen moeten gebeuren, dan wordt er een voorstel
uitgewerkt voor alle wijzigingen, dat dan wordt verstuurd naar alle mensen die
hier invloed van zullen ondervinden. 


docs/thesis/lokaalreservaties.org ¶

3 additions and 3 deletions.

View changes Hide changes

Het inplannen van de lokalen op de UHasselt is een complexe opdracht. In het
onderzoek is naar voren gekomen dat deze opdracht onnodig ingewikkelder wordt
gemaakt.

*** De huidige software
Het huidige programma blijkt een overblijfsel te zijn van de Economische
Hogeschool. Sindsdien zijn er geen aanpassingen meer gebeurd, en volgens het
personeel dat ermee werkt, is dat zeer merkbaar.

De broncode is volgens <PERSOON> geschreven in Delphi, maar ik heb twijfels
hierbij, want dit strookt niet direct met het feit dat dit programma nog van de
hierbij, want dit strookt niet direct met het feit dat dit programma nog van de
EHL komt.[fn:chronology] Ik vermoed dat Turbo Pascal gebruikt werd, dit zou dan
ook verklaren waarom de software op een aparte computer draait.

[fn:chronology] De Economische Hogeschool ging op in het Limburgs Universitair
Centrum eind jaren 80, maar Delphi kwam pas uit in 1995. Misschien zijn er later
nog wijzigingen gebeurd, maar dat is niet zeker.

Het programma vereist ook dat het op een aparte computer wordt gedraaid. Ook dit
sterkt het vermoeden dat het programma in Turbo Pascal geschreven werd, daar
deze wel werkt op MS-DOS.

Een ander groot probleem is dat het programma gewoon te traag is. Bij te veel
aanpassingen wordt het onwerkbaar traag, en regelmatig crasht het gewoon.

Daarbovenop is de functionaliteit behoorlijk beperkt; alhoewel het wel mogelijk
is om rekenbladen of foto's uit het programma op te vragen, is simpele tekst
niet mogelijk.

**** Toekomst van het programma
Ik vermoed dat de huidige software niet meer bruikbaar is; alhoewel een
programma onderhouden vaak een betere keuze is dan het volledig opnieuw
schrijven, is het probleem dat dat onderhoud /al twintig jaar uitgesteld is/.
Voor de gebruikte programmeertaal ervaren programmeurs vinden is op zich al een
opdracht, en het integreert nu al niet meer met recente besturingssystemen. Mijn
inziens lijkt het beter dat er wordt uitgekeken naar een andere oplossing. Deze
opmerking is strijdig met die van de gebruikers van het programma zelf; zij
hebben de wens geuit dat het programma toch wordt gerepareerd, voornamelijk
omdat ze dit programma kennen. Misschien dat begeleiding met een nieuw programma
de overgang naar een eventuele vervanging draagelijker kan maken.

**** Alternatieven
 Dit probleem is niet nieuw; er is al door het personeel zelf gezocht naar
 mogelijke alternatieve software. Twee voorstellen kwamen prominent naar boven.

 Het eerste voorstel is *Porto*, met de Universidade do Porto als toepasselijke
 origine. Dit werd zelfs proactief aangevoerd door de ontwikkelaars zelf,
 inclusief een bijbehorend onderhoudscontract voor twee jaar. De prijs bedroeg
 echter €10000, en dat was te duur.

 Het tweede is een combinatie van twee gekoppelde systemen, *Syllabus +
 Enterprise/Classic*. In tegenstelling tot Porto wordt dit programma al gebruikt
 op Belgische bodem door de UCLL en KUL. Het bezit veel van de benodigde
 functies, maar de werking viel niet in goede aarde, alhoewel het personeel zelf
 vermoedt dat dit een kwestie van smaak is.

*** Onthouden
Een ander groot probleem met lokalen inplannen is dat veel informatie uit het
hoofd onthouden moet worden. Dit is dan info zoals het aantal zitplaatsen in
lokalen, de software die op de computers geïnstalleerd staat, ... Deze info kan
gemakkelijk met de computer onthouden worden, maar dit gebeurd gewoon niet. Dit
geeft dan ook grote problemen als een personeelslid ziek wordt en tijdelijk
wegvalt; eventuele vervanging heeft simpelweg geen toegang tot belangrijke info.

*** Manuele processen
Veel zaken die praktisch gezien makkelijk geautomatiseerd kunnen worden,
vereisen nog steeds veel menselijke interventie. Een externe reservering loopt
via de Dienst Communicatie, waarbij vooral e-mails gebruikt worden om te
communiceren met andere personeelsleden. Een gelijkaardig proces geldt voor
wijzigingen van de docenten uit; zij contacteren het personeel rechtstreeks,
maar ook via e-mail.

Deze processen zijn voor verbetering vatbaar, en voorstellen worden aangevoerd
in <DEEL III - NOG INVULLEN>.


*** In het kort

Het is duidelijk dat de manier van hoe lokalen gereserveerd worden toe is aan
een grondige verbetering. Niet alleen is de ruggengraat van het proces toe aan
een vervanging (of op z'n minst een grondige revisie), er moet gewerkt worden
aan manieren om tijdrovend werk om te zetten in geautomatiseerde processen, om
de kostbare tijd van het personeel effectiever in te zetten.

Het volledige rapport is te vinden in [[AppendixA][Appendix A]].



docs/thesis/master.org ¶

24 additions and 2 deletions.

View changes Hide changes

#+language: nl
#+latex_class: report
#+latex_class_options: [a4paper]
#+latex_header: \usepackage{pdfpages}
#+latex_header: \usepackage{biblatex}
#+latex_header: \bibliography{sources}
#+latex_header: \usepackage[dutch]{babel}
#+OPTIONS: toc:nil
#+OPTIONS: H:6
#+author: Maarten Vangeneugden @@latex:\\@@ prof. dr. Wim Lamotte
#+date: 2017-2018
#+title: Joeni
#+subtitle: Bachelorproef voorgedragen tot het behalen van de graad van bachelor in de informatica
#+TOC: headlines 6

#+INCLUDE: "./voorwoord.org"

* Onderzoek
#+INCLUDE: "./uurrooster.org"
#+INCLUDE: "./lokaalreservaties.org"
#+INCLUDE: "./lokaalreservaties.org"
#+INCLUDE: "./examens.org"
#+INCLUDE: "./inplannen.org"


* Joeni
#+INCLUDE: "./softwarekeuzes.org"

#+INCLUDE: "./client-side-scripting.org"
#+INCLUDE: "./courses.joeni.org"
#+INCLUDE: "./curriculum.joeni.org"
#+INCLUDE: "./databank.joeni.org"
#+INCLUDE: "./dienstmededelingen.org"
#+INCLUDE: "./instellingen.joeni.org"
#+INCLUDE: "./lokalen.joeni.org"
#+INCLUDE: "./mededelingen.joeni.org"
#+BEGIN_COMMENT
#+INCLUDE: "./postgres.org"
#+END_COMMENT
#+INCLUDE: "./rooster.joeni.org"
#+INCLUDE: "./verbeteringspunten_joeni.org"

* Voorstellen voor informatieprocessen


* Informatieprocessen en algemene verbeteringen

#+INCLUDE: "./aandachtspunten.org"

#+INCLUDE: "./huisstijl.org"
#+INCLUDE: "./implementatie_uhasselt.org"
#+INCLUDE: "./toekomst.org"

* Dankwoord
#+INCLUDE: "./dankwoord.org"















@@latex:\printbibliography@@
* Appendices



* COMMENT Structuur
- Titelblad
- Inhoudsopgave
- Voorwoord/Inleidende tekst
- Hoofdstuk 1 - Onderzoek
- Hoofdstuk 2 - Beschrijving Joeni
- Hoofdstuk 3 - Voorstellen verbetering UHasselt / Bedachte processen
- Dankwoord
- Bibliografie
- Appendices 


docs/thesis/postgres.org ¶

1 addition and 1 deletion.

View changes Hide changes

De praktische uitwerking van het project maakt gebruik van de
PostreSQL-databanktechnologie. Bij deze databank is onderzoek verricht naar de
mogelijkheden die het biedt.
** Integriteit van data
Het is vitaal om zoveel mogelijk data te laten valideren door de databank zelf,
of minstens via een soort "validatielaag" rondom de databank. Deze validatielaag
is dan verantwoordelijk om alle aangebrachte data op correctheid te controleren.
Voorbeelden van te controleren data zijn dan:
- IBAN- en BIC-codes van studenten en personeelsleden die kloppen
- Rijksregisternummers die kloppen
- Geen mogelijkheid om lokalen te reserveren die onreserveerbaar zijn
- Geen conflicterende reservaties van bepaalde lokalen
- ...
Diezelfde validatielaag geeft dan aan alle data *zekerheid van correctheid* mee:
Als alle ingevoerde data valide is, dan zal bij logische implicatie, alle
uitgevoerde data ook valide zijn. \\
Naar toekomstperspectief is dit van onmisbaar belang voor vele instanties, en de
UHasselt is hierop geen uitzondering.

De datavalidatie zorgt ook bij de programmatuur voor verbetering: Er hoeft enkel
gecontroleerd te worden of de ingevoerde data valide is. De validatielaag kan
eventueel foutcodes terugsturen, die dan een bepaalde fout aanduiden. \\
Met andere woorden: Er hoeft enkel bij opslaan in de databank gecontroleerd te worden op
correctheid. Bij opvragen van informatie kunnen er met valide data zelfs
automatisch zekerheden aangenomen worden. Bijvoorbeeld: Als de databank steeds
valideert dat een lokaalreservatie tussen 08:00 en 24:00 plaatsvindt, dan hoeft
een programma dat lokaalreservaties weergeeft enkel een tabel met die uren weer
te geven, en hoeven uren van voor 08:00 niet weergegeven te worden.
** Django models en validators
Django geeft de mogelijkheid om dergelijke beveiligingen en validatielagen in
het systeem in te bouwen. Het moet wel gesteld worden dat deze zekerheden niet
doorgepropageerd worden naar de databank zelf (omdat dit niet in een databank
kan worden geïmplementeerd), maar slechts gecontroleerd worden bij invoer via
een programma dat via Django de databank aanspreekt. Bij [[FIX LINK][toekomstige
implementaties]] moet hiermee rekening gehouden worden. Een lijst van alle te
valideren voorwaarden is gepubliceerd in deze thesis, [[FIX LINK][bijlage ?]].
valideren voorwaarden is gepubliceerd in deze thesis, [[FIX LINK][bijlage ?]].


docs/thesis/sources.bib ¶

63 additions and 1 deletion.

View changes Hide changes

author = "UHasselt",
title  = "Q\&A ALIPA",
year   = "2017",
number = "1",
journal = "Nu weet je het",
pages  = "4-5",
url    = "https://www.uhasselt.be/documents/Tijdschriften/nUweetjeHet/personeelsblad-februari-2017-klein.pdf"
}

@article{jaarverslag-2017,
author = "UHasselt",
title  = "2017 in cijfers",
year   = "2017",
journal  = "Jaarverslag 2017",
pages  = "6",
url    = "https://www.uhasselt.be/Documents/UHasselt/algemeen/jaarverslagen/2017/jaarverslag-2017.pdf"
}

@article{strafwetboek-valsheid-informatica,
author = "Belgische federale regering",
title  = "Strafwetboek/Code pénal",
chapter= "IV",
series = "IIbis",
number = "Artikel 210bis",
url   = "http://www.ejustice.just.fgov.be/cgi_loi/loi_a1.pl?language=nl&la=N&cn=1867060801&table_name=wet&&caller=list&fromtab=wet&tri=dd+AS+RANK#LNK0052"
}

@online{blackboard-privacy-policy,
title = "Blackboard Privacy Statement",
author = "dr.h.c.mult. Richard M. Stallman",
title  = "Who does that server really serve?",
url    = "https://www.gnu.org/philosophy/who-does-that-server-really-serve.html"
}

@report{eu-gdpr,
url   = "https://eur-lex.europa.eu/eli/reg/2016/679/oj",
title = "REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016",
subtitle = "on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)",
date = "2016-04-27",
author = "European Parliament, Council of the European Union"
}

@online{bb-tos,
url   = "http://www.blackboard.com/legal/terms-of-use.html",
title = "Terms Of Use"
}

@online{bb-privacy-policy,
title = "Blackboard Privacy Statement",
date  = "2018-05-24",
url   = "https://www.blackboard.com/legal/privacy-policy.html"
}

@article{bb-blackout,
url   = "https://web.archive.org/web/20101115105111/http://blogs.palmbeachpost.com/extracredit/2008/04/18/blackboard-blackout/",
author = "Kim Miller",
title = "Blackboard Blackout",
date = "2008-04-18"
}

@article{bb-blackout2,
url   = "https://web.archive.org/web/20110926094431/http://media.www.thehunterenvoy.com:80/media/storage/paper1327/news/2009/02/18/News/Portal.Problems.Blackboard.Blackout-3635795.shtml",
author = "Jonathan Jordan",
date = "2009-02-18",
title = "Portal Problems, Blackboard Blackout",
subtitle = "Data Systems at CUNY Malfunction and Disrupt Classes"
}

@article{bb-crash,
url   = "http://itintheuniversity.blogspot.com/2007/11/in-recent-chronicle-article-outlining.html",
author = "Luke Fernandez",
title = "Blackboard catastrophic system crash in Utah",
date = "2007-11-27"
}

@article{bb-dataloss,
url   = "http://bpeacock22.blogspot.com/2009/01/great-blackboard-crash-of-09.html",
title = "The Great Blackboard Crash of 09",
author = "Benjamin s.s.t.t.",
date = "2009-01-21"
}

@online{ufora,
url   = "https://www.ugent.be/nl/actueel/lms-ufora.htm",
title = "De nieuwe Minerva heet Ufora",
author = "Universiteit Gent",
date = "2018-06-17"
}

@online{opleiding-informatica,
url   = "https://www.uhasselt.be/documents/BROCHURES/2018-2019/Master-Informatica-2018-web.pdf",
title = "Master in de Informatica",
year = "2018",
author = "Universiteit Hasselt"
}


docs/thesis/toekomst.org ¶

67 additions and 17 deletions.

View changes Hide changes

Joeni is op dit moment een kant-en-klare oplossing voor de problemen die
BlackBoard en het studentendossier stellen aan de UHasselt.

 Joeni is op dit moment een voorbeeld van een kant-en-klare oplossing voor de problemen die
 BlackBoard en het studentendossier stellen aan de UHasselt.

Maar software is steeds in beweging, en is nooit af. Daarom dat ik hier enkele
punten voorzie omtrent de toekomstige uitbreidingen die aan Joeni zouden kunnen
worden toegevoegd.

 punten voorzie omtrent de toekomstige uitbreidingen die aan Joeni zouden kunnen
 worden toegevoegd, of aan eender welk ander programma dat als vervanging zou dienen.[fn:still-joeni]

** /Desktop/-applicatie
Op dit moment wordt Joeni gebruikt via een webbrowser. Maar dit hoeft niet per
sé.
Een mooie (latere) uitbreiding voor Joeni, is dat de software uitgebreid wordt
met een applicatie die direct op de computers van de gebruikers kan werken.

gebruikt om "een vervangende applicatie" te beschrijven, alhoewel dit eender welk
ander programma kan zijn. Indien het specifiek om Joeni gaat, zal dit ook
duidelijk blijken uit de context.

Dit opent vanzelfsprekend mooie nieuwe toepassingen, zoals integratie met
/desktop features/ (zoals notificaties in de werkbalk), gemakkelijk door de
bestanden kunnen scrollen op een computer, verhoogde snelheid, dynamische
veranderingen in de interface, /direct messaging/ ...

 Op dit moment wordt Joeni gebruikt via een webbrowser, maar dit is zeker niet
 wat het eindpunt zou moeten zijn.

De data wordt natuurlijk vanaf de server gehaald (net zoals Joeni op dit moment
de data opvraagt). Hiervoor is geen aanpassing nodig aan de bestaande databank.

 aan hun gebruikers bieden; ze zijn van nature statische tekstbestanden, die
 enkel informatie kunnen doorsturen, en (gestructureerd) via speciale
 HTML-formulieren informatie kunnen opvangen. Daar komen dan ook een hoop
 beveiligingsproblemen bij kijken, die inherent zijn aan websites.

 Joeni moet een programma worden dat op de computer zelf draait. Veel features
 die nu simpelweg niet mogelijk zijn in Joeni, zouden hiermee wel mogelijk
 worden:
- Pop-ups die aangeven als er een wijziging is gebeurd in het uurrooster :: Nu
     moeten studenten zelf naar die webpagina surfen, er wordt geen proactieve
     melding hiervan gemaakt. Veel agendaprogramma's geven hier ook geen melding
     van, dus via iCal zal dit ook niet lukken.
- Live chat :: Dit is meer een feature die naar Agora toe gericht is, maar een
               live chat is ook technisch niet mogelijk zonder /client-side
               scripting/. Dit zou een uiterst handige toepassing zijn voor
               groepswerken, waarvoor studenten nu nog altijd zijn aangewezen op
               programma's van derden.
- Offline halen van studiemateriaal :: Het is triviaal, maar Joeni werkt enkel
     met een internetverbinding, net zoals *elke webapplicatie van de UHasselt*.
     Een "echt" programma kan al het studiemateriaal, meldingen, opdrachten, ...
     downloaden op de computer van de student, zodat dit altijd offline
     geraadpleegd kan worden. Het indienen van taken kan dan ook offline
     gebeuren, waarna het programma zelf bij de eerstvolgende netwerkverbinding
     de taak doorstuurt.
- Veel betere samenhang/snelheid :: Een webapplicatie impliceert dat alle pagina's
     telkens opnieuw moeten worden ingeladen, er zit dus altijd een soort van
     /delay/ tussen een klik van de gebruiker en de uiteindelijke reactie. De
     browser moet ook alles inladen en /renderen/, dus een supersnelle cache
     alleen zal nooit het snelheidsprobleem kunnen oplossen. En als de
     verbinding wegvalt tijdens het inladen, dan is Joeni plots niet meer
     bereikbaar, redelijk frustrerend. Een programma op de computer zelf heeft
     al deze problemen niet. Er kan ook gebruik gemaakt worden van een hoop
     andere /widgets/ (zoals tabs in hetzelfde venster) die de samenhang verder
     kunnen verhogen.
- Dynamische/Directe informatie :: Als de gebruiker een fout maakt bij de
     interactie met de website, dan kan hier pas melding van worden gemaakt als
     de pagina opnieuw wordt ingeladen. Met een applicatie op de computer kunnen
     direct meldingen worden gegeven, en kan het indienen onmogelijk worden
     gemaakt totdat de gebruiker alle problemen heeft opgelost. Het geeft ook
     zekerheid: Als een knop wordt ingedrukt, dan is er zekerheid dat de
     verandering correct werd doorgevoerd.

De reden dat er voor Joeni toch gekozen is voor een webapplicatie om te
beginnen, is omdat het niet zozeer de bedoeling was dat Joeni "het eindpunt" zou
worden, maar eerder een voorstelling van hoe het eruit zou kunnen zien. Het zou
Joeni ook complexer maken: Rekening houden met dynamische veranderingen, pop-ups
inbouwen (waarvan de API's kunnen verschillen per besturingssysteem), ... Het
maakt het geheel veel moeilijker om te bouwen, maar voegt weinig toe voor deze bachelorproef.
Daarom dat een website het idee van Joeni veel beter overbrengt, maar dan wel in
een statische setting.\\
Daarbij is een groot deel van de code in de achtergrond (voornamelijk de
databasecode) overdraagbaar, daar een desktopapplicatie sowieso contact zal
moeten onderhouden met een databank.


docs/thesis/uurrooster.org ¶

0 additions and 2 deletions.

View changes Hide changes

1	-	gegenereerd wordt, en hoe er gedacht is aan mensen met een kleurenstoornis.
2	-

docs/thesis/uurroosters.org ¶

4 additions and 4 deletions.

View changes Hide changes

Alle studenten beschikken over uurroosters die informatie verschaffen omtrent
hun weekplanning. Er zijn echter verschillende problemen met het huidige
systeem.

*** 3 verschillende systemen
In plaats van dat er één uurrooster is dat de meest relevante informatie
weergeeft, zijn er een hoop verschillende manieren om aan het rooster te
geraken.
**** Gewone uurroosters
Op [[collegeroosters.uhasselt.be][deze pagina]] moeten studenten hun faculteit
ingeven[fn:why-sit], daarop hun academiejaar, en dan het nummer van de week
ingeven[fn:why-sit], daarop hun academiejaar, en dan het nummer van de week
die ze willen inkijken. Daarop wordt een "interactieve" gif-afbeelding
ingeladen waarop de uren van een modeltraject worden weergegeven.

[fn:why-sit] Om een onbekende reden wordt de studierichting Informatica apart
geklasseerd onder de faculteit "SIT", maar dit is onjuist; deze studierichting
valt onder de faculteit Wetenschappen.

Dit systeem heeft verschillende problemen:
- Werkt niet zonder JavaScript :: Alhoewel dit makkelijk zonder JS kan werken,
     werkt de website niet als scripts uitgeschakeld zijn. [[why-no-js][Dat vormt een probleem]].
- Weeknummers i.p.v. gewone data :: Ik ken geen mensen die bijhouden welke week
- Weeknummers i.p.v. gewone data :: Ik ken geen mensen die bijhouden welke week
     van het jaar het is. We houden wel bij welke dag het is, en de meesten
     plannen ook in op dagen.
- Opent niet automatisch op huidige week :: Veelal wordt het uurrooster gecheckt
     omdat men wilt weten wat er deze week gebeurd.
- HTML én PDF :: Men kan zowel een HTML-pagina openen, als een PDF-bestand.
                 Waarom dat nodig is is niet geweten, maar het maakt de
                 achterliggende applicatie wel complexer om te onderhouden.
- Enkel modeltraject :: Veel studenten volgen een GIT-traject, maar zij moeten
     met dit systeem vaak 2 á 3 keer opnieuw het proces doorlopen om
     verschillende uurroosters zelf naast elkaar te leggen.
- Niet up-to-date :: Uit het onderzoek [LINK-NAAR-ONDERZOEK][bleek dat dit
     uurrooster niet up-to-date is, en slechts 1 keer per dag wordt vernieuwd].
     Zeker bij snelle wijzigigen voor bv. gastcolleges is dit uurrooster onbetrouwbaar.
     [[Vergadering 1][bleek dat dit uurrooster niet up-to-date is, en slechts 1 keer per dag wordt vernieuwd]].
     Zeker bij snelle wijzigigen voor bv. gastcolleges is dit uurrooster onbetrouwbaar.
Kleine opmerking bij het iCal-bestand dat op de pagina staat: Alhoewel de
iCal-specificatie velden specifieert voor locatie, wordt alle informatie over
een bepaalde gebeurtenis in de titel van het evenement geplaatst.
**** Dynamische uurroosters
[[https://uhintra03.uhasselt.be/uurroosters/][Deze uurroosters]] Zijn een directe verbetering op de [[Gewone uurroosters][gewone uurroosters]]; ze zijn
up-to-date, openen op de huidige week en geven slechts 1 resultaat (een
HTML-pagina). De resterende problemen blijven echter bestaan.
**** Uurrooster Studentendossier
Er is ook de mogelijkheid om een gepersonaliseerd uurrooster op te vragen
[[https://uhintra02.uhasselt.be/studdosst/sdsUurrooster.aspx][via het studentendossier]]. Deze geeft wél een GIT-traject, maar is nogal
omslachtig om te bereiken en ziet er erg gedateerd uit. Er is ook geen
mogelijkheid om een iCal-bestand te verkrijgen, dus voor de meest relevante
informatie moeten studenten steeds naar deze website surfen. Doordat het
JavaScript vereist is een simpele /web scraper/ schrijven ook niet echt triviaal
om te doen.
**** Nood aan eengemaakt systeem
Wat op dit moment bestaat is ontoereikend voor de vereisten van de studenten. De
systemen zijn omslachtig, complex en ze voelen gedateerd aan (en zijn dat ook).
Daarnaast is drie verschillende applicaties onderhouden sowieso gecompliceerder
dan maar ééñ onderhouden.

In Joeni wordt dan ook een eengemaakt uurrooster voorgesteld, dat poogt al deze
problemen op te lossen.


docs/thesis/verbeteringspunten_joeni.org ¶

18 additions and 0 deletions.

View changes Hide changes

Alhoewel Joeni wel degelijk een positieve invloed kan hebben op de
IT-infrastructuur van UHasselt, zijn er nog steeds enkele punten die een
beperking kunnen opleveren. Deze punten worden in dit hoofdstuk toegelicht.
*** Algemeen
*Joeni is niet volledig in het Nederlands*. Sommige onderdelen worden wel in een
 andere taal weergegeven dan Engels, maar deze zijn vaak automatisch via het
 Django-framework vertaald (zoals de namen van dagen). Hier dient wel
 genuanceerd te worden dat Blackboard eveneens niet in het Nederlands is. Voor
 Joeni was meertalig zijn geen prioriteit, en dus is er meer aandacht besteedt
 aan het maken van een volledig /functioneel/ programma, dan een volledig
 /vertaald/ programma. Moest Joeni echter later ook ingezet worden binnen de
 UHasselt, dan is vertalen in Nederlands, Frans, Duits, ... uiterst simpel: Alle
 infrastructuur om te vertalen is al aanwezig in het Django-framework zelf. In
 de code zijn alle te vertalen blokken ook gemarkeerd.
**** Missende pagina's
Niet alle pagina's zitten in Joeni en het is zeker niet mogelijk om direct Bb.
en Std. te vervangen. Er is hier ook een afweging gemaakt tussen complexiteit en
functionaliteit.\\
Tijdens het schrijven van Joeni werd snel duidelijk dat veel functionaliteit van
Std. verouderd is, en het herimplementeren zou dus nooit nodig zijn. Een goed
voorbeeld hiervan is de link naar het JOS-project van de VDAB[fn:jobteaser]: De link die op
het Std. te vinden is, wordt nu automatisch doorverwezen naar de hoofdpagina van
de VDAB. Sommige attesten op Std. worden ook uitgegeven door bepaalde diensten,
en daarvan kan natuurlijk niet op voorhand geweten zijn welke attesten.

Sommige pagina's konden gewoonweg niet gereproduceerd worden, omdat ze links
genereren naar bepaalde PDF-bestanden.

[fn:jobteaser] Op dit moment blijken de links naar het JOS-project offline
gehaald te zijn, en vervangen door een ander systeem genaamd "Jobteaser", maar
het is maar de vraag hoe lang deze links blijven staan.
*** Uurrooster
Het uurrooster biedt *geen mogelijkheid om planning van andere richtingen in te kijken*.
Ik vermoed niet dat dit iets is wat veel mensen zullen missen, maar dit
kan wel later worden toegevoegd als dit nodig blijkt te zijn. Joeni heeft dit
niet omdat het de bedoeling was om een zo simpel mogelijk systeem te ontwerpen
dat zoveel mogelijk mensen tegemoet komt. De mogelijkheid om planningen in te
kijken van andere studierichtingen is niet nuttig genoeg om te toevoeging ervan
te verantwoorden.

De *vorm van de weergave van de week* was een kritiekpunt op zich van een van de
testers; die merkte op dat de breedte van de verschillende dagen niet gelijk is.
Dit klopt ook: Dagen zonder "evenementen" worden dunner weergegeven dan dagen
waarop wel iets gebeurt. De argumentering hiervan is tweeledig: Enerzijds is het
logisch om belangrijkere zaken (een bezette dag) prominenter weer te geven dan
onbelange zaken (een vrije dag), en dat wordt bekomen door ze breder te maken.
Anderzijds vereist elke dag even breed maken extra opmaakcode.\\

*** Lokalen
Dit moet grotendeels worden ingevuld met *recente* informatie over de lokalen op
de UHasselt. Volgens Ines Boonen is er geen systeem informatie bijhoudt over de
lokalen, het is dus zeer waarschijnlijk dat de bestaande informatie dan ook niet
meer up-to-date is. Dit is natuurlijk gemakkelijk te remediëren door een dag de
universiteit rond te trekken en alle informatie te verzamelen.

Dit is op dit moment nog niet gedaan voor Joeni, omdat dit geen prioriteit was
van het project. Er zijn enkele voorbeeldlokalen ingevoerd om te laten zien dat
het systeem goed werkt en bruikbare informatie verschaft, maar langs alle
lokalen van de UHasselt gaan behoort niet tot de /scope/ van dit proefwerk.

*** Prikbord
Niet alle diensten die op het prikbord iets kunnen zetten, kunnen aangeven wie
een bepaald bericht kan zien. Tot nu toe kan enkel de examencommissie bepalen
wie een bericht mag zien, omdat de meeste van hun berichten toch gericht zijn
aan een enkele student.\\
Dit is nog niet geïmplementeerd omdat nog niet zeker is wat de meest
waarschijnlijke manier is dat informatie gedeeld wordt door de verschillende
diensten. Vermoedelijk zijn de meeste berichten toch bedoeld voor alle studenten
(getuige de PDF's die studeerruimte aanbieden), maar het kan natuurlijk dat
sommige berichten enkel aan een bepaalde studierichting getoond moeten worden.

*** Agora?
Nieuwe studenten kunnen zich via de website voorinschrijven op de UHasselt.
Alhoewel dit mooi geïntegreerd zou kunnen worden in Joeni, is er toch beslist
dit niet te doen.[fn:prereg-table]

Ten eerste is dit niet echt per sé nodig: Ook al vereist de voorinschrijving het
gebruik van /client side scripting/, het is niet zo doorgedreven als bij andere
onderdelen van de website. Daarnaast de pagina er esthetisch gezien nog goed
genoeg uit.\\
Ten tweede: Dit is een pagina waar haast alle studenten maar één keer in hun
hele leven mee in contact zullen komen. Om hiervoor een pagina toe te voegen aan
Joeni is nogal overbodig, er zijn namelijk tal van andere mogelijke
verbeteringen die veel vaker gebruikt zullen worden.
*** Agora?
Het originele project was groter dan wat Joeni op dit moment is; het eerste
voorstel omvatte ook een universitair communicatieplatform waarop studenten,
docenten en vakgroepen makkelijk met elkaar konden communiceren. Naast
Administratie en Vakken zou dit onderdeel Agora noemen.\\
Maar Agora staat in het menu doorgekrast. Uiteindelijk zit het niet in Joeni,
voornamelijk omwille van de grootte van het project, maar ook omdat het niet
direct tot een basistaak van de universiteit behoort. 

De tabellen die Agora mogelijk maken zijn echter a

[fn:prereg-table] voor volledigheid van de databank is er wel een tabel
aangemaakt waarin de voorinschrijvingen kunnen worden opgeslagen, ~~PreRegistration~~.


docs/verslagen.org → docs/thesis/verslagen.org ¶

1 addition and 1 deletion.

View changes Hide changes

** praktische informatie
 - locatie :: kantoor wim lamotte, edm
 - tijd :: [2017-11-30 thu 11:00-11:30]
 - aanwezigen :: 
   - maarten vangeneugden :: student
   - prof. dr. wim lamotte :: promotor
 - onderwerp :: eerste ontmoeting omtrent bachelorproef

** samenvatting gesprek
 maarten heeft eerder een e-mail gestuurd naar lamotte om de voortgang van de
 bachelorproef te bespreken.
 deze voortgang werd uitgedrukt door enkele getekende er-diagrammen van de
 databank.

 maarten stelt de voorziene opdeling voor: 3 applicaties, draaiend op hetzelfde
 platform:
 - administration :: implementeert functionaliteit van het [[https://uhintra02.uhasselt.be/studdosst/][studentendossier]]
 - agora :: ondersteunend sociaal platform voor studenten en personeel van de
            uhasselt
 - courses :: implementeert functionaliteit van [[https://bb.uhasselt.be][blackboard]]

 de databank implementeert de basisvereisten, maar kan/moet nog fel uitgebreid
 worden. deze uitbreidingen kunnen op vraag van derden toegevoegd worden aan het
 systeem.

** aangebrachte punten door promotor
 - kerntaken van de universiteit :: de universiteit moet niet per sé voorzien in
      het bouwen van een sociaal systeem, behoort niet tot de kerntaken. kan
      volgens lamotte ook "gemakkelijk geswitched worden tussen verschillende
      diensten".
      er wordt op dit moment gedacht gebruik te maken van google drive.
      maarten brengt aan dat een gespecialiseerde oplossing volgens hem beter tot
      z'n recht komt voor een organisatie als een universiteit, maar dit
      verandert natuurlijk niets aan het feit dat dit geen kerntaak is van de
      uhasselt.
 - administration en courses prioritair :: dit behoort namelijk wel tot de
      kerntaken, en vereist gespecialiseerde software. de prioriteit ligt volgens
      lamotte dus duidelijk op het afmaken van deze onderdelen. de grootte van de
      bachelorproef vereist dan ook dat er prioriteiten worden vooropgesteld.
 - groepen voor vakken :: (dit gaat niet over de studiegroepjes die studenten
      kunnen oprichten) sommige vakken hebben zoveel studenten dat het niet
      mogelijk is die op dezelfde momenten in eenzelfde college onder te brengen.
      deze moeten kunnen worden onderverdeeld in verschillende studiegroepen.
 - prioriteitenlijst opstellen :: opnieuw, omwille van de grootte van het
      project, vraagt lamotte om een lijst op te stellen van wat maarten ziet als
      de prioriteiten van de proef, en hoe deze uitgevoerd zullen worden. dit
      moet een informele lijst zijn van de prioriteiten, zodat deze ook door
      mensen zonder informatia-achtergrond relatief makkelijk te begrijpen is.

** actiepunten/afspraken
 - maarten zal een prioriteitenlijst opstellen en die doorsturen naar de
   promotor.
 - promotor zal proberen bruno janssen te betrekken bij de volgende afspraak.
 - maarten verplaatst werkzaamheden van agora naar administration en courses.

* Vergadering Ines Boonen
[2018-03-05 Mon 14:00-15:45]
Ben samengekomen met Ines Boonen om meer details te verkrijgen over de manier
waarop uurroosters worden samengesteld. Zij zat samen in hetzelfde kantoor met
personeel dat de andere faculteiten aandeed (Ines doet enkel fac.
Wetenschappen), dus ik heb een redelijk klare kijk gekregen op het proces.

** Wanneer
Informatie over de uurroosters komen het hele jaar doorlopend binnen:
- Wijzigingen
- Reservaties van externe partijen
- Reservaties van studentenverenigingen

De informatie van de richtingen zelf komt meestal binnen begin juli. Er wordt
echter al proactief gevraagd vanaf begin maart om de uurroosters van het 1ste
semester volgend academiejaar in te plannen.

** Kunnen er nu eisen aan reservaties gesteld worden?
*Neen.* Alleszins niet automatisch of gestructureerd.

De dienst onthoudt de eigenschappen van reservaties uit het hoofd. Alhoewel
enkel reserveerbare lokalen in de lijst verschijnen (personeelskantoren (en alle
niet-reserveerbare lokalen in feite) worden niet weergegeven), wordt er enkel
aangegeven hoeveel zitplaatsen er in een lokaal zijn, en of er al dan niet al
iets ingepland is.

** Manuele pogingen
Er worden soms manueel pogingen ondernomen om bepaalde handigheiden te
verkrijgen:
- Soms wilt een prof 2 aparte lokalen. Er wordt dan geprobeerd om die 2 lokalen
  dan langs elkaar te reserveren.
- Het is beter om een groep studenten een hele voor- of namiddag in hetzelfde
  lokaal te houden. Dit is puur voor logistieke redenen (gangen niet overbelasten)
- Er wordt geprobeerd om lokalen een volledige dag vrij te houden. Dit wordt
  onderling besproken met "de tafel" om wat rond te schuiven.

** Rekening mee te houden
- Alle modeltrajecten :: Vakken uit modeltrajecten mogen niet overlappen. Met
  GIT-studenten wordt op dit moment geen rekening gehouden (alhoewel het
  technisch wel mogelijk kan zijn om dat te regelen zodat studenten geen
  overlappingen hebben in hun curricula)
- Schakelstudenten :: Sommige schakeljaren nemen ook vakken op van het lopende
  masterjaar, maar niet alle vakken. Er dient dus rekening gehouden te worden
  dat schakelstudenten én gewone masterstudenten beide al hun vakken kunnen
  volgen (voor zover ze het modeltraject volgen)
- Lawaaioverlast :: Sommige ingeplande reservaties veroorzaken lawaaioverlast.
                    Er wordt dan rekening gehouden dat reservaties die stilte
                    vereisen in een bepaalde radius niet worden ingepland.
- Faciliteitsstudenten :: Deze studenten kunnen langer doorwerken aan hun
     examens, maar dit moet _manueel_ worden onthouden. Het is niet mogelijk om
     dit aan te geven of hier rekening mee te houden bij het plannen van de uurrooters.

** Proces voor externe reservering
1. Studentenvereniging / externe partij dient aanvraag in bij Dienst
   Communicatie (in verband met huur) (Johan bij dienst com. doet dit)
2. Dienst Communicatie vraagt Ines Boonen voor lokaalreservatie in te plannen op
   basis van gegeven parameters
3. Ines Boonen stuurt e-mail naar Dienst Communicatie met details
4. Dienst Communicatie koppelt dit terug naar reserveerder

Interne diensten (zoals bv. het secretariaat) kunnen zelf kijken of er lokalen
vrij zijn, en dan gewoon zelf een reservatie doorvoeren.

*** Punten voor verbetering
- Met GNU Taler is het mogelijk een betalingssysteem op te bouwen, waarmee
  externe partijen parameters kunnen opgeven, waarop het systeem automatisch een
  reservatie opstelt. Voor speciale aanvragen (met bepaalde eisen) kan er dan
  nog altijd naar de Dienst communicatie gestuurd worden, waarbij het
  bovenstaande proces plaatsvindt.
- Voor reservaties door studentenverenigingen is het misschien mogelijk dat ze
  zelf met Ines contact opnemen? (Bij speciale eisen. Anders kan dat ook volgens
  het gewone proces, zelfs rond GNU Taler om want zij kunnen gratis reserveren.)

** Proces voor wijziging van docenten uit
1. Docent stuurt aanvraag wijziging via e-mail (GMail, privacy in gevaar!) naar
   Ines Boonen
2. Ines Boonen tracht aan de gestelde voorwaarden te voldoen, en de wijziging in
   reservatie door te voeren
3. Ines Boonen stuurt e-mail terug met informatie over de wijziging, en of het
   al dan niet gelukt is om de reservatie te verplaatsen
*** Punten voor verbetering
Het is duidelijk dat dit volledig door de docent zelf kan gedaan worden. Deze
geeft dan in het programma de vereiste parameters in. Het programma controleert
de curricula van alle studenten die dat vak volgen (opdat de wijziging geen
conflict veroorzaakt), en doet een voorstel voor andere lokalen, tegemoetkomend
aan de gegeven parameters.

Moest er geen oplossing gevonden worden (bv. steeds conflict, niet voldaan aan
voorwaarden), dan kan het programma misschien een oplossing voorstellen die een
parameter negeert? \\
In elk geval: Het blijft wel mogelijk om Ines Boonen een e-mail te sturen moest
het niet automatisch gaan, en
natuurlijk ook als het een reservatie met speciale eigenschappen betreft.

** Proces voor opstellen van semestriële uurroosters
1. Docenten sturen documenten (op papier/in .docx) in met vereisten, tijden dat
   ze niet beschikbaar zijn, welke docent wat geeft (zodat docenten soms kunnen
   worden ingewisseld om ze vrij te krijgen voor andere momenten), ...
2. De dienst lokaalreservaties neemt het uurrooster van het vorige jaar bij
   wijze van sjabloon, en begint daarvan de nodige wijzigingen aan te brengen.
3. Resultaten worden voorgelegd aan de betrokken personeelsleden, en eventuele
   reacties achteraf worden in acht genomen (er kunnen dus nog wat wijzigingen
   gemaakt worden).
*** Punten voor verbetering
De vereisten komen binnen in papiervorm... Dit is dus zeer gemakkelijk te
automatiseren, als de docenten maar gewoon in een programma ingeven wat hun
vereisten zijn. Op dit moment moet het personeel dit allemaal manueel ingeven,
en zo kunnen er fouten ontstaan. Het vreemde is dat deze data via docx-bestanden
wordt gestuurd. Hier kunnen namelijk ook weer fouten in optreden, en Word is
sowieso iets dat vermeden dient te worden.

** Waarom kunnen studenten niet reserveren?
Te vervelend.

Studenten gebruiken de lokalen te vaak om te eten/drinken, om dingen te doen die
niet studeren zijn, ... Ze laten soms de lokalen ook vuil achter en dan komen er
klachten binnen. Door dat misbruik is het voor hen niet mogelijk om dat te doen.

Het maakt het ook een stuk moeilijker voor de dienst lokaalreservaties om hun
werk te doen; er is sowieso al een tekort aan lokalen op de UHasselt, en als
studenten ook nog beginnen te reserveren zal het helemaal niet meer lukken om
nog /last minute/ wijzigingen voor colleges bv. door te voeren. \\
Soms komen studenten ook gewoon niet opdagen en dan is dat natuurlijk een lokaal
weggegooid.

Het compromis was vroeger om de lijst van lokaalreservaties van die dag af te
drukken en op te hangen, maar dit wordt niet meer gedaan omdat dit te omslachtig
is.

Een middenweg zou natuurlijk kunnen zijn dat de lokaalreservaties online kunnen
worden bekeken door studenten, via de website.

** Perspectief van de ontwikkelaar
In de databank zouden volgende eigenschappen van een lokaal moeten worden
bijgehouden (exclusief wat ik al in het schema zou bijhouden):
- Tafels staan vast of los (voor bv. groepsprojecten willen sommigen dat die
  verplaatst kunnen worden)
- Aantal stopcontacten
- Buitenraam aanwezig of niet
- Welke programma's op de computers staan (omwille van de propriëtaire software
  staan bepaalde programma's niet altijd op alle computers)

*Dit moet ook geüpdatet worden!* Op dit moment worden *alle* aanvragen via die
dienst gestuurd (omdat zij bepaalde informatie gewoon uit het hoofd geleerd
hebben), maar als deze ook in de databank staat kunnen docenten regelmatig
gemakkelijk zélf wijzigingen doorvoeren.

Reservaties kunnen plaatsvinden van 08:00 - 22:00. Voor latere reservaties (tot
24:00) moet er echter beveiliging worden gevraagd (Securitas). Dit vereist dus
een tijdige reservering.

*** Huidige situatie
Het gebruikte programma is volgens Ines ~20 jaar oud. Het zou geschreven zijn in
VB.NET maar dat is onmogelijk, .NET kwam pas in 2002 uit. Door de ouderdom van
de software werkt deze hoogstens op Windows 7, Windows 10 kan het niet aan.

De software is ook zéér volatiel en traag. Het aanpassen van de uurroosters gaat
ontzettend traag, waardoor de uurroosters pas 's nachts worden geüpdatet. (Het
dynamisch uurrooster geeft echter wel de onmiddelijke situatie weer). Bij te
veel aanpassingen vertraagt het systeem tot een onwerkbare snelheid, en bij
bepaalde aanpassingen crashet het zelfs onverbiddelijk. Edwin (?) houdt voor de
software zelfs een oude computer draaiende naast de gewone server, want zonder
dat computertje werkt dit programma gewoon niet meer.

De software is geschreven voor de Economische Hogeschool van vroeger, maar is
duidelijk niet mee geëvolueerd met de noden van een universiteit van >6000
studenten, met al hun speciale noden en curricula.


** Output
Het is via het gebruikte programma enkel mogelijk om een Excel-rekenblad of een
foto (de .gifs van de uurroosters) te outputten. Simpele tekst is niet mogelijk,
alhoewel de data wel wordt bijgehouden op een externe server (in een databank).
Software kan dit dan gemakkelijk uitlezen.

** Voorgestelde alternatieven
Geen enkel voorgesteld alternatief is vrije software (afgeleid uit de
prijskaartjes). Voor de volledigheid noteer ik hier toch nog de speerpunten.
*** Porto
Project van de universiteit van Porto. Dit werd door hen voorgesteld aan de
UHasselt ter gebruik, met een 2-jarig onderhoudscontract. \\
Voorgestelde prijs van ~ €10.000 was echter te hoog. Hilde Cleeren wist mij te
vertellen dat dit systeem gebruikt wordt in sommige Scandinavische universiteiten.
*** Syllabus + Enterprise/Classic
Gebruikt door UCLL en KUL. Bezit enorm veel van de gevraagde features:
- Houdt eigenschappen van lokalen bij (bv. aantal computers, zitplaatsen, ...)
- Waarschuwt automatisch voor overlappingen bij opstellen uurroosters en
  wijzigingen
- Doet zelf voorstellen voor een bepaalde wijziging, op basis van gegeven
  parameters
- Kan blijkbaar geïntegreerd worden met de agenda's van bv. professoren, zodat
  onvrije momenten niet ingepland kunnen worden
- Houdt ook informatie over examenroosters bij (huidige systeem doet dit niet)

Personeel verklaart echter dat ze het systeem niet fijn werken vinden, maar
vermoeden dat dat vooral een kwestie van smaak is; ze zijn het huidige systeem gewoon.

*** Eduflex
Grotendeels zoals Syllabus+, maar meer informatie niet gegeven.

*** Untis
Gebruikt op de PXL, maar meer informatie was nog niet beschikbaar.

** Voorrangsregels
Gastprofessoren en -sprekers, docenten van andere universiteiten, ... *hebben
absoluut voorrang.* Hun schema's zijn haast niet aan te passen.

Daarna hangt het vooral af van de specifieke vereisten van docenten.

** Keuzevakken en groepen
Voor veel richtingen worden de studenten opgedeeld in groepen. Deze groepen
zijn al dan niet zelf te kiezen, of worden toegewezen door de planners van het
uurrooster (bv. Ines Boonen).

Gemakkelijkheidshalve worden deze groepen (indien mogelijk) ingedeeld volgens
hun keuzevakken. Mensen die Spaans volgen komen dan in groep A/B/C terecht, en
diegenen die Duits volgen in groep D/E/F.

Het zou echter handig zijn mocht de naam van de docent _niet_ verschijnen als de
studenten zich zelf in groepen moeten indelen. Het blijkt dat studenten dan gaan
kiezen voor een bepaalde docent.

** Andere weetjes
- Het semestersysteem wordt de standaard binnen haast alle opleidingen. Voor
  eerstejaars blijft echter soms nog het kwartielsysteem behouden, voor een
  enkele richting is elk jaar een kwartielsysteem (4 kwartielen).
- Sommige studierichtingen zijn wel ingedeeld in groepen, maar zijn dit enkel op
  papier. In het systeem wordt dit dan niet opgeslagen. Dit moet dan manueel
  ingegeven worden.
- Het is mogelijk dat ze zelfs reservaties ontvangen die pas over 2 jaar
  plaatsvinden.
- Lokalen worden 's ochtends door "materiaalmeesters" geopend. Als een lokaal
  voor een dag niet gereserveerd is, dan wordt dat lokaal ook niet geopend.
- Soms zijn er speciale eisen bij een lokaalreservatie (bv. er moet een TV
  geplaatst worden of zo, een experiment, ...). Deze nota verschijnt dan bij de
  lokaalreservatie, waarvan de materiaalmeesters op de hoogte worden gebracht
  (zij kunnen dit namelijk inkijken).
- Hilde Cleeren Heeft voorgesteld om de studenten op te delen in klasselijsten. Volgens
  haar kan ze zo makkelijk zien hoeveel studenten een overlap hebben bij een
  bepaalde wijziging. Als dat 1-2 studenten zijn wordt dat soms gedaan, alleen
  wordt er dan wel gezorgd dat die student volgende week zeker _niet_ overlap
  hebben. Als er bv. 10 studenten overlap hebben wordt het nooit gedaan.

** Conclusie
Het grootste probleem is volgens het personeel dat er te veel onthouden moet
worden; informatie die gemakkelijk door het systeem kan worden bijgehouden
(zoals bv. het aantal computers in een lokaal, of een lokaal überhaupt een
computerlokaal is, ...) wordt nu middels "ervaring" onthouden. Dit resulteert
van tijd tot tijd in menselijke fouten in de planning. 

Het uurrooster van het vorige academiejaar als sjabloon nemen is redelijk
handig. Er kan dan ook direct door de computer vastgelegd worden of een docent
wijzigingen moet hebben of niet.

Het huidige programma is waarschijnlijk verloren. Dit zal echter afhangen van de
gebruikte programmeertaal, maar naar de toekomst toe zie ik het niet zitten. Het
programma is inefficiënt, heeft onverklaarbare momenten van traagheid, crashet
en vereist een oude, externe computer omdat het niet draait op een recent
besturingssysteem.
Een duurzaam en robuust nieuw programma dringt zich op. Het personeel uit echter
de wens dat het huidige programma wat herschreven wordt, om de opgedane ervaring
hiermee makkelijk over te dragen. Ik vermoed echter dat een volledig nieuw programma
dat niet te fel afwijkt van het huidige programma in het humane aspect, zeker
geaccepteerd zal worden.

De aangebrachte alternatieven zijn misschien toereikend in functionaliteit, maar
omdat het geen vrije software betreft zou het gebruik hiervan uiteindelijk in
problemen resulteren die met vrije software makkelijk voorkomen kunnen worden (omwille van de
controle die men heeft over vrije software). De huidige software is vrij (intern
geschreven door cel ISA), maar is waarschijnlijk niet meer te onderhouden. Ook
door de aard van het bedrijf zelf (Universiteit Hasselt) lijkt een nieuwe,
intern geschreven oplossing de enige oplossing op lange termijn. (Men kan ook
een extern bedrijf inschakelen, maar het is maar de vraag of zij bereid zijn een
vrije oplossing aan te reiken.) \\
*** Onderhoudscontract als substituut voor vrije software
Het onderhoudscontract van de oplossing van de Universiteit van Porto is
ontoereikend als substituut voor vrije software; men verliest de controle om
zelf de software te wijzigen naar eigen goeddunken. Het verbindt ons ook
onlosmakelijk aan de ontwikkelaars, en het contract geldt maar voor 2 jaar.
Niets houdt de ontwikkelaar tegen om exorbitante prijzen te vragen voor
verlenging. De ontwikkelaar heeft die macht dan, omdat overschakelen op een
andere oplossing tegen dan te duur zal zijn. Met een vrijesoftwareoplossing
heeft de ontwikkelaar die macht niet.

* Vergadering Bruno Janssen
[2018-03-08 Thu 15:00-16:00]
Afspraak gemaakt voor een "verkennende vergadering" met Bruno Janssen. Hij is
eindverantwoordelijke voor de ICT en heeft een beslissende stem binnen het
ALIPA-project. 
** Huidige staat is slecht
Bruno Janssen schuwt de grote woorden niet en noemt de huidige situatie "ronduit
slecht", volgens hem moet je de situatie ook benoemen zoals ze is, zonder rond
de pot te draaien.
*** Voorbeeld: vergaderingen
 Als iemand een vergadering wilt organiseren, dan komt er heel wat gepruts bij
 kijken; moeten er hapjes voorzien worden, extra stoelen, koffie, een beamer,
 ... voor al deze zaken moet er naar verschillende nummers getelefoneerd worden.
 Dit is een voorbeeld van een vaak voorkomend probleem dat makkelijk
 geautomatiseerd kan worden, maar in plaats daarvan moeten we alles manueel zelf
 regelen.
** Andere punten
- Er zijn verschillende programma's voor de examenroosters en voor de
  uurroosters te maken, en beide worden dus op een andere manier gedaan.
- ir. Janssen raadt mij aan om, omwille van de omvang van het project, mijn
  praktische uitwerking te beperken tot het studentengedeelte. Ik neem dit
  advies ter harte, omwille van het feit dat ik al +3 jaar hiermee in contact
  kom, ben ik hier het beste op de hoogte van de noden van het systeem.
** Beleidstop
De beleidstop heeft de boodschap die ir. Janssen verkondigd begrepen. Heden is
er een meerjerenplan op touw, omdat van de ene dag op de andere alles omgooien
niet haalbaar is. 
** Uitbesteden
ir. Janssen gelooft dat het uitbesteden van de software-ontwikkeling een beter
idee is dan de programma's zelf schrijven.
Hiervoor laat hij enkele voorbeeldprogramma's zien die niet zelf zijn
geschreven:
- Fintra :: Een programma om financiën te beheren
- Ultimo :: Dient om werkopdrachten rond te sturen
Er is blijkbaar ook een programma om het autopark te beheren, alsook een hoop
andere programma's. Ik mocht van ir. Janssen aanwijzen op het scherm waar ik
meer info over wilde, maar ik wist niet waar te beginnen.
*** Google
Om het standpunt van uitbesteding kracht bij te zetten, laat hij me ook zien hoe
fel Google geïntegreerd wordt in het systeem van de studenten: dit omvat
- GMail
- Google Calendar
- Google Drive
- Google Docs
- Google Sheets
- Google Slides
- Google Meet
- Google Chat
- ...
*Al deze diensten biedt Google gratis aan.* Alhoewel ik het niet met die woorden
heb gezegd, kon ik me niet van de gedachte ontdoen dat hier iets sinister achter
zat van Google uit. Ik zal dit in m'n thesis verder ter sprake brengen.
** Andere vragen
Omdat ir. Janssen niet direct op al m'n vragen kan antwoorden, wordt er
afgesproken dat ik een e-mail stuur met de nog resterende vragen, waarna hij me
dan verdere uitleg zag verschaffen, of doorverwijzen naar de mensen die me met
die vragen kunnen helpen.

* Vergadering Peter Vandoren
[2018-03-08 Thu 16:00-17:30]

Deze vergadering gebeurt in het kader van het opstellen van de :quurroosters. Voor
de richting Informatica is dat blijkbaar een afwijkend proces.

** Algemene situatie
Er bestaat over het algemeen 1 jaarkalender, maar voor elke richting is die
ietsjes anders.
Voorbeeld: Master of Statistics:
2 kwartielen in tweede jaar wegens /time management/-problemen
-> 1 kwartiel volledig voor de proefthesis


** Techniek om uurrooster op te stellen
Er wordt een lijstje aan stappen overlopen:
1. (*Basisvraag*) Wat zijn de onderwijsmethoden? Hoe wordt er les gegeven? (Dit
   verschilt bv. fel tussen Geneeskunde en Architectuur)
2. Vorm van onderwijs geven; In het 1ste bachelorjaar is dit vaak begeleide
   zelfstudie, naarmate de jaren vorderen evolueert het steeds verder naar
   volledig zelfstandig leerstof verwerken.

Deze verschillende vormen van onderwijs geven zijn bepalende factoren; er wordt
namelijk getracht een zo logisch mogelijke dag voor de studenten in te plannen.
Idealiter vormen de eerste momenten van de dag de hoorcolleges, is er daarna een
periode van zelfstudie, die dan wordt afgesloten met een responsiecollege.

Dit is echter niet de manier waarop elke richting werkt, dus alles heeft zijn
eigen aanpassingen en subtiliteiten.

** Professoren
Een van de _grootste_ problemen met het inplannen van de uurroosters, zijn de
professoren. Deze zijn druk bezet, en flexibiliteit is moeilijk te verwachten
van hen. Assistenten daarentegen kunnen makkelijk de werkzittingen doen (die
kunnen variëren over de dag), en zijn flexibeler in te zetten.

** Informatica
Een speciaal punt in de richting Informatica: Vanaf 3BACH (en dus ook 1MAS,
2MAS) worden er enkel nog maar hoorcolleges ingepland. (de bachelorproef wordt
enkel ingepland als advies)

Dit heeft veel te maken met de grote hoeveelheid verschillende lessen (door de
specialisaties) die er per week plaatsvinden; het is simpelweg niet mogelijk om
voor al die lessen meer dan enkel de hoorcolleges in te plannen; er zouden
sowieso overlappingen ontstaan, waardoor modeltrajectstudenten sommige lessen
niet zouden kunnen volgen.

Het is echter mogelijk hierop in te spelen, zie [[Software als oplossing?][verder]].

*** Jaaropstelling
In tegenstelling tot bij andere richtingen (die halfjaarlijks werken) wordt er
bij Informatica geprobeerd om een volledig jaar in 1 keer op voorhand uit te
plannen. Dit om de proffen hun schema's zo vroeg mogelijk te bezorgen.

** Frequentie van een vak
Hoeveel lesuren zijn er nodig voor een vak? Bijkomend: Hoe lang moet een sessie
duren; 1 uur, 2 uren, ...?

Op basis van hoe deze frequentie voor de verschillende vakken is, wordt een dag
in een jaarkalender opgedeeld in een bepaald aantal blokken.

Voorbeeld: Master of Statistics is opgedeeld in 2 blokken:
- BLOK 1 :: Voor 12:00
- BLOK 2 :: Na 12:00

Dit wordt niet officieel zo ingepland, maar contactmomenten tussen professoren
en studenten worden op die manier onderling afgesproken.

Voorbeeld: Master Informatica:
Hier zijn 6 verschillende profielen, met minstens 4 vakken elk.
Primair wordt er gezorgd dat geen van de vakken binnen een bepaald profiel
overlappen, daarna worden de andere profielen in overeenstemming gebracht.
Deze richting werkt met 4 blokken op één dag.

** Sjablonen
Er wordt haast altijd uitgegaan van de situatie van het vorige jaar, dit wordt
dan als sjabloon gebruikt.
Als er geen veranderingen zijn, dan worden er geen wijzigingen aangebracht.

Van tijd tot tijd vindt er echter een grote verandering plaats (zoals bij bv.
2de Master of Statistics; die moest recen volledig vervangen worden)
*** Als vakken van een richting veranderen
*** Als vakken van een richting veranderen
1. Er wordt gekeken naar hoe en wat veranderd
2. Er wordt een voorstel voor een wijziging uitgewerkt
3. Voorstellen aan betrokken partijen
   (Het is vaak mogelijk om a.d.h.v. het aantal studiepunten van een vak het
   aantal hoorcolleges te bepalen, maar dit kan variëren)

Als alles in orde is, wordt het programma naar het secretariaat gestuurd. Zij
plannen de verschillende vakken in voor de lokalen.


------

De reden dat niet iedereen gewoon 1 keer per jaar samenkomt om alle schema's op
te stellen, is omdat het gedaan moet zijn vóór de zomervakantie begint.

Dit proces is namelijk ook /volledig offline/: er is totaal geen zicht op de
agenda's van de proffen.

De huidige manier van werken is dat er met minimaal overleg gewoon en voorstel
wordt gedaan aan de proffesoren. Die zijn meestal gewoon meegaand met het
voorstel, behoudens enkele kleine aanpassingen.

** Software als oplossing?

Dit hele probleem is met de juiste input volledig te automatiseren met een
programma. Het zou dan wel bv. ook rekening moeten houden met studenten die hun
curriculum in het midden van het jaar aanpassen, rekening houden met lokalen,
weet hebben over de agenda's van professoren, ...

Een mogelijke oplossing zou backtracking kunnen zijn; als een oplossing niet kan
werken, teruggaan naar de laatste mogelijk correcte oplossing, en van daar
verder werken.

Buiten het schrijven van het programma zelf, is een van de meest complexe
opdrachten dan, om alle betrokkenen zo snel mogelijk al de benodigde informatie
te laten aanleveren: Op dit moment komt de informatie nogal druppelgewijs
binnen, en moeten nieuwigheden naderhand in een schema verwerkt worden (dat
waarschijnlijk al geaccepteerd is door iedereen). Het maakt het allemaal stukken
moeilijker om gewoon een uurrooster op te stellen.


1	-	De UHasselt gebruikt al jaren BlackBoard als digitaal platform voor het
2	-	uitwisselen van studiemateriaal tussen docenten en studenten.\\
3	-	** Propriëtaire software
4	-	*** Service as a software substitute (SaaSS)
5	-	** Kostelijk
6	-	<Uit goede bron heb ik kunnen vernemen dat BlackBoard de UHasselt jaarlijks
7	-	~€100.000 euro kost.>....
8	-	** Geen huisstijl mogelijk
9	-	** Onstabiel
10	-	** Slechte reputatie
11	-

1	1	Web-applicaties worden blootgesteld aan tal van mogelijke beveiligingsproblemen.
2	2	Een beetje /cracker/ kan een onbeveiligde website in weinig tijd
3	3	binnendringen.\\
4	4	Mede dankzij het gebruik van Django zijn de meeste mogelijke veiligheidslekken
5	5	gedicht. De belangrijkste onderwerpen (en gemaakte afwegingen) worden hier uitgelegd.
6	6	** Cross site scripting
7	7	Cross site scripting (XSS) laat toe om scripts te injecteren in de browsers van andere
8	8	gebruikers door bv. scripts op te slaan in de databank, die dan later worden
9	9	uitgelezen en op de computer van andere gebruikers wordt uitgevoerd.
10	10
11	11	Binnen Django wordt XSS opgelost door middel van
12	12	/[[https://docs.djangoproject.com/en/2.0/ref/templates/language/#automatic-html-escaping][automatic HTML escaping]]/; de data die gebruikers ingeven, wordt behandeld als "onveilig".
13	13	*** Orgmode
14	14	Binnen Joeni kan gebruik worden gemaakt van Orgmode-syntax om teksten van
15	15	opmaak te voorzien, zoals vette tekst, hyperlinks, lijsten enz.
16	16
17	17	Het is technisch gezien ook mogelijk om broncode in Org te markeren, zelfs om
18	18	deze uit te laten voeren, met alle [[https://orgmode.org/org.html#Code-evaluation-security][veiligheidsrisico's]] die daaruit volgen.
19	19
20	20	Ik heb toch geopteerd om Orgmode-syntax toe te laten voor data die door
21	21	gebruikers wordt verstuurd, maar enkel voor personeel van de UHasselt.
22	22	Personeelsleden kunnen makkelijker aansprakelijk gehouden worden voor misbruik
23	23	van de hen aangeleverde voorrechten, en de mogelijke gevolgen van dergelijk misbruik
24	24	zullen volgens mij afdoende werken om XSS via Orgmode tegen te gaan. Moest dat
25	25	niet kloppen, dan kan Orgmode altijd gemakkelijk uitgeschakeld worden, slechts
26	26	met een tolereerbaar verlies aan opmaak binnen Joeni.
27	27
28	28	** Externe malafide programmatuur
29	29	Bij het opvragen van scripts buiten de eigen server is er steeds een risico dat
30	30	er malafide code wordt binnengehaald; men weet niet welke acties ondernomen
31	31	worden op die andere servers om kraken tegen te gaan.\\
32	32	Dit is al verscheidene keren voorgevallen <BRONNEN>, en de kern van het probleem is tot nu
33	33	toe nog altijd niet opgelost, omdat het niet kán worden opgelost: Downloaden van
34	34	ongecontroleerde scripts houdt een inherent veiligheidsrisico in.
35	35
36	36	Joeni lost dit op door simpelweg _geen_ externe scripts in te laden. Dit is
37	37	namelijk ook een reden waarom /client-side scripting/ overal vermeden wordt;
38	38	het opent een deur tot problemen waarover geen interne controle mogelijk is.
39	-
+	39
40	40	Alle software, media, /stylesheets/, bibliotheken, ... worden vanaf de server
41	41	gedraaid.
42	42	** Clickjacking
43	43
44	44	** Cross site request forgery
45	45	Cross site request forgery (CSRF)
46	46
47	47	** Kraken van wachtwoorden en -zinnen
48	48	*** Geen verplichte wijzigingen
49	49

1	1	Naast het reserveren van lokalen, is er ook het werk van inplannen van de uren
2	2	van de vakken zelf.
3	3
4	4	De manieren verschillen voornamelijk per faculteit. Het volledige verslag is te vinden in
5	5	[[APPENDIX A - ...]].
6	-
+	6
7	7	De manier van inplannen verschilt bij de richting Informatica enigzins van die
8	8	van de andere richtingen binnen de faculteit Wetenschappen: Vanaf het derde
9	9	bachelorjaar worden er enkel nog hoorcolleges meer ingepland.
10	10
11	11	De oorzaak hiervan is het grote aantal specialisaties die de masteropleiding
12	12	heeft. (De andere richtingen hebben enkel een bachelorgedeelte) Voor deze vakken
13	13	meer dan enkel de hoorcolleges inplannen is onmogelijk, omdat anders er
14	14	overlappingen onstaan binnen modeltrajecten.
15	15
16	16	*** Professoren
17	17	De agenda's van de professoren worden naar voren geschoven als het primaire probleem tijdens
18	18	het opstellen van een planning: Ze zijn druk bezet, en hun afspraken zijn
19	19	moeilijk te verplaatsen.\\
20	20	Om hieraan tegemoet te komen, wordt vaak de planning van het vorige jaar als een
21	21	sjabloon genomen. Meestal komt de planning nog voldoende overeen met de vorige
22	22	versie (zeker als er geen modeltrajectwijzigingen plaatsvonden).
23	23
24	24	*** Sjablonen
25	25	Om het inplannen zo makkelijk mogelijk te laten verlopen, wordt er steeds
26	26	vertrokken van de planning van het vorige academiejaar als sjabloon.
27	27	Als er geen veranderingen zijn, dan worden er geen wijzigingen aangebracht.
28	28
29	29	Indien er toch aanpassingen moeten gebeuren, dan wordt er een voorstel
30	30	uitgewerkt voor alle wijzigingen, dat dan wordt verstuurd naar alle mensen die
31	31	hier invloed van zullen ondervinden.
32	32

1	1	Het inplannen van de lokalen op de UHasselt is een complexe opdracht. In het
2	2	onderzoek is naar voren gekomen dat deze opdracht onnodig ingewikkelder wordt
3	3	gemaakt.
4	4
5	5	*** De huidige software
6	6	Het huidige programma blijkt een overblijfsel te zijn van de Economische
7	7	Hogeschool. Sindsdien zijn er geen aanpassingen meer gebeurd, en volgens het
8	8	personeel dat ermee werkt, is dat zeer merkbaar.
9	9
10	10	De broncode is volgens <PERSOON> geschreven in Delphi, maar ik heb twijfels
11	-	hierbij, want dit strookt niet direct met het feit dat dit programma nog van de
+	11	hierbij, want dit strookt niet direct met het feit dat dit programma nog van de
12	12	EHL komt.[fn:chronology] Ik vermoed dat Turbo Pascal gebruikt werd, dit zou dan
13	13	ook verklaren waarom de software op een aparte computer draait.
14	14
15	15	[fn:chronology] De Economische Hogeschool ging op in het Limburgs Universitair
16	16	Centrum eind jaren 80, maar Delphi kwam pas uit in 1995. Misschien zijn er later
17	17	nog wijzigingen gebeurd, maar dat is niet zeker.
18	18
19	19	Het programma vereist ook dat het op een aparte computer wordt gedraaid. Ook dit
20	20	sterkt het vermoeden dat het programma in Turbo Pascal geschreven werd, daar
21	21	deze wel werkt op MS-DOS.
22	22
23	23	Een ander groot probleem is dat het programma gewoon te traag is. Bij te veel
24	24	aanpassingen wordt het onwerkbaar traag, en regelmatig crasht het gewoon.
25	25
26	26	Daarbovenop is de functionaliteit behoorlijk beperkt; alhoewel het wel mogelijk
27	27	is om rekenbladen of foto's uit het programma op te vragen, is simpele tekst
28	28	niet mogelijk.
29	29
30	30	**** Toekomst van het programma
31	31	Ik vermoed dat de huidige software niet meer bruikbaar is; alhoewel een
32	32	programma onderhouden vaak een betere keuze is dan het volledig opnieuw
33	33	schrijven, is het probleem dat dat onderhoud /al twintig jaar uitgesteld is/.
34	34	Voor de gebruikte programmeertaal ervaren programmeurs vinden is op zich al een
35	35	opdracht, en het integreert nu al niet meer met recente besturingssystemen. Mijn
36	36	inziens lijkt het beter dat er wordt uitgekeken naar een andere oplossing. Deze
37	37	opmerking is strijdig met die van de gebruikers van het programma zelf; zij
38	38	hebben de wens geuit dat het programma toch wordt gerepareerd, voornamelijk
39	39	omdat ze dit programma kennen. Misschien dat begeleiding met een nieuw programma
40	40	de overgang naar een eventuele vervanging draagelijker kan maken.
41	41
42	42	**** Alternatieven
43	43	Dit probleem is niet nieuw; er is al door het personeel zelf gezocht naar
44	44	mogelijke alternatieve software. Twee voorstellen kwamen prominent naar boven.
45	45
46	46	Het eerste voorstel is Porto, met de Universidade do Porto als toepasselijke
47	47	origine. Dit werd zelfs proactief aangevoerd door de ontwikkelaars zelf,
48	48	inclusief een bijbehorend onderhoudscontract voor twee jaar. De prijs bedroeg
49	49	echter €10000, en dat was te duur.
50	50
51	51	Het tweede is een combinatie van twee gekoppelde systemen, *Syllabus +
52	52	Enterprise/Classic*. In tegenstelling tot Porto wordt dit programma al gebruikt
53	53	op Belgische bodem door de UCLL en KUL. Het bezit veel van de benodigde
54	54	functies, maar de werking viel niet in goede aarde, alhoewel het personeel zelf
55	55	vermoedt dat dit een kwestie van smaak is.
56	56
57	57	*** Onthouden
58	58	Een ander groot probleem met lokalen inplannen is dat veel informatie uit het
59	59	hoofd onthouden moet worden. Dit is dan info zoals het aantal zitplaatsen in
60	60	lokalen, de software die op de computers geïnstalleerd staat, ... Deze info kan
61	61	gemakkelijk met de computer onthouden worden, maar dit gebeurd gewoon niet. Dit
62	62	geeft dan ook grote problemen als een personeelslid ziek wordt en tijdelijk
63	63	wegvalt; eventuele vervanging heeft simpelweg geen toegang tot belangrijke info.
64	64
65	65	*** Manuele processen
66	66	Veel zaken die praktisch gezien makkelijk geautomatiseerd kunnen worden,
67	67	vereisen nog steeds veel menselijke interventie. Een externe reservering loopt
68	68	via de Dienst Communicatie, waarbij vooral e-mails gebruikt worden om te
69	69	communiceren met andere personeelsleden. Een gelijkaardig proces geldt voor
70	70	wijzigingen van de docenten uit; zij contacteren het personeel rechtstreeks,
71	71	maar ook via e-mail.
72	72
73	73	Deze processen zijn voor verbetering vatbaar, en voorstellen worden aangevoerd
74	74	in <DEEL III - NOG INVULLEN>.
75	-
+	75
76	76	*** In het kort
77	77
78	78	Het is duidelijk dat de manier van hoe lokalen gereserveerd worden toe is aan
79	79	een grondige verbetering. Niet alleen is de ruggengraat van het proces toe aan
80	80	een vervanging (of op z'n minst een grondige revisie), er moet gewerkt worden
81	81	aan manieren om tijdrovend werk om te zetten in geautomatiseerde processen, om
82	82	de kostbare tijd van het personeel effectiever in te zetten.
83	83
84	84	Het volledige rapport is te vinden in [[AppendixA][Appendix A]].
85	-
+	85

1	1	#+language: nl
2	2	#+latex_class: report
3	3	#+latex_class_options: [a4paper]
4	4	#+latex_header: \usepackage{pdfpages}
5	5	#+latex_header: \usepackage{biblatex}
6	6	#+latex_header: \bibliography{sources}
7	7	#+latex_header: \usepackage[dutch]{babel}
8	8	#+OPTIONS: toc:nil
9	9	#+OPTIONS: H:6
10	10	#+author: Maarten Vangeneugden @@latex:\\@@ prof. dr. Wim Lamotte
11	11	#+date: 2017-2018
12	12	#+title: Joeni
13	13	#+subtitle: Bachelorproef voorgedragen tot het behalen van de graad van bachelor in de informatica
14	14	#+TOC: headlines 6
15	15
16	16	#+INCLUDE: "./voorwoord.org"
17	17
18	18	* Onderzoek
19	19	#+INCLUDE: "./uurrooster.org"
20	-	#+INCLUDE: "./lokaalreservaties.org"
+	20	#+INCLUDE: "./lokaalreservaties.org"
21	21	#+INCLUDE: "./examens.org"
22	22	#+INCLUDE: "./inplannen.org"
23	23
+	24
24	25	* Joeni
25	26	#+INCLUDE: "./softwarekeuzes.org"
26	27
+	28	#+INCLUDE: "./client-side-scripting.org"
+	29	#+INCLUDE: "./courses.joeni.org"
+	30	#+INCLUDE: "./curriculum.joeni.org"
+	31	#+INCLUDE: "./databank.joeni.org"
+	32	#+INCLUDE: "./dienstmededelingen.org"
+	33	#+INCLUDE: "./instellingen.joeni.org"
+	34	#+INCLUDE: "./lokalen.joeni.org"
+	35	#+INCLUDE: "./mededelingen.joeni.org"
+	36	#+BEGIN_COMMENT
+	37	#+INCLUDE: "./postgres.org"
+	38	#+END_COMMENT
+	39	#+INCLUDE: "./rooster.joeni.org"
+	40	#+INCLUDE: "./verbeteringspunten_joeni.org"
+	41
27	42	* Voorstellen voor informatieprocessen
28	-
+	43
+	44	* Informatieprocessen en algemene verbeteringen
+	45
29	46	#+INCLUDE: "./aandachtspunten.org"
30	47
+	48	#+INCLUDE: "./huisstijl.org"
+	49	#+INCLUDE: "./implementatie_uhasselt.org"
+	50	#+INCLUDE: "./toekomst.org"
+	51
31	52	* Dankwoord
32	53	#+INCLUDE: "./dankwoord.org"
33	54
34	55
35	56
36	57
37	58
38	59
39	60
40	61
41	62
42	63
43	64
44	65
45	66
46	67
47	68
48	69	@@latex:\printbibliography@@
49	70	* Appendices
50	71
+	72
51	73
52	74	* COMMENT Structuur
53	75	- Titelblad
54	76	- Inhoudsopgave
55	77	- Voorwoord/Inleidende tekst
56	78	- Hoofdstuk 1 - Onderzoek
57	79	- Hoofdstuk 2 - Beschrijving Joeni
58	80	- Hoofdstuk 3 - Voorstellen verbetering UHasselt / Bedachte processen
59	81	- Dankwoord
60	82	- Bibliografie
61	83	- Appendices
62	84

1	1	De praktische uitwerking van het project maakt gebruik van de
2	2	PostreSQL-databanktechnologie. Bij deze databank is onderzoek verricht naar de
3	3	mogelijkheden die het biedt.
4	4	** Integriteit van data
5	5	Het is vitaal om zoveel mogelijk data te laten valideren door de databank zelf,
6	6	of minstens via een soort "validatielaag" rondom de databank. Deze validatielaag
7	7	is dan verantwoordelijk om alle aangebrachte data op correctheid te controleren.
8	8	Voorbeelden van te controleren data zijn dan:
9	9	- IBAN- en BIC-codes van studenten en personeelsleden die kloppen
10	10	- Rijksregisternummers die kloppen
11	11	- Geen mogelijkheid om lokalen te reserveren die onreserveerbaar zijn
12	12	- Geen conflicterende reservaties van bepaalde lokalen
13	13	- ...
14	14	Diezelfde validatielaag geeft dan aan alle data zekerheid van correctheid mee:
15	15	Als alle ingevoerde data valide is, dan zal bij logische implicatie, alle
16	16	uitgevoerde data ook valide zijn. \\
17	17	Naar toekomstperspectief is dit van onmisbaar belang voor vele instanties, en de
18	18	UHasselt is hierop geen uitzondering.
19	19
20	20	De datavalidatie zorgt ook bij de programmatuur voor verbetering: Er hoeft enkel
21	21	gecontroleerd te worden of de ingevoerde data valide is. De validatielaag kan
22	22	eventueel foutcodes terugsturen, die dan een bepaalde fout aanduiden. \\
23	23	Met andere woorden: Er hoeft enkel bij opslaan in de databank gecontroleerd te worden op
24	24	correctheid. Bij opvragen van informatie kunnen er met valide data zelfs
25	25	automatisch zekerheden aangenomen worden. Bijvoorbeeld: Als de databank steeds
26	26	valideert dat een lokaalreservatie tussen 08:00 en 24:00 plaatsvindt, dan hoeft
27	27	een programma dat lokaalreservaties weergeeft enkel een tabel met die uren weer
28	28	te geven, en hoeven uren van voor 08:00 niet weergegeven te worden.
29	29	** Django models en validators
30	30	Django geeft de mogelijkheid om dergelijke beveiligingen en validatielagen in
31	31	het systeem in te bouwen. Het moet wel gesteld worden dat deze zekerheden niet
32	32	doorgepropageerd worden naar de databank zelf (omdat dit niet in een databank
33	33	kan worden geïmplementeerd), maar slechts gecontroleerd worden bij invoer via
34	34	een programma dat via Django de databank aanspreekt. Bij [[FIX LINK][toekomstige
35	35	implementaties]] moet hiermee rekening gehouden worden. Een lijst van alle te
36	-	valideren voorwaarden is gepubliceerd in deze thesis, [[FIX LINK][bijlage ?]].
+	36	valideren voorwaarden is gepubliceerd in deze thesis, [[FIX LINK][bijlage ?]].
37	37

1	1	author = "UHasselt",
2	2	title = "Q\&A ALIPA",
3	3	year = "2017",
4	4	number = "1",
5	5	journal = "Nu weet je het",
6	6	pages = "4-5",
7	7	url = "https://www.uhasselt.be/documents/Tijdschriften/nUweetjeHet/personeelsblad-februari-2017-klein.pdf"
8	8	}
9	9
10	10	@article{jaarverslag-2017,
11	11	author = "UHasselt",
12	12	title = "2017 in cijfers",
13	13	year = "2017",
14	14	journal = "Jaarverslag 2017",
15	15	pages = "6",
16	16	url = "https://www.uhasselt.be/Documents/UHasselt/algemeen/jaarverslagen/2017/jaarverslag-2017.pdf"
17	17	}
18	18
19	19	@article{strafwetboek-valsheid-informatica,
20	20	author = "Belgische federale regering",
21	21	title = "Strafwetboek/Code pénal",
22	22	chapter= "IV",
23	23	series = "IIbis",
24	24	number = "Artikel 210bis",
25	25	url = "http://www.ejustice.just.fgov.be/cgi_loi/loi_a1.pl?language=nl&la=N&cn=1867060801&table_name=wet&&caller=list&fromtab=wet&tri=dd+AS+RANK#LNK0052"
26	26	}
27	27
28	28	@online{blackboard-privacy-policy,
29	-	title = "Blackboard Privacy Statement",
+	29	author = "dr.h.c.mult. Richard M. Stallman",
+	30	title = "Who does that server really serve?",
+	31	url = "https://www.gnu.org/philosophy/who-does-that-server-really-serve.html"
+	32	}
+	33
+	34	@report{eu-gdpr,
+	35	url = "https://eur-lex.europa.eu/eli/reg/2016/679/oj",
+	36	title = "REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016",
+	37	subtitle = "on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)",
+	38	date = "2016-04-27",
+	39	author = "European Parliament, Council of the European Union"
+	40	}
+	41
+	42	@online{bb-tos,
+	43	url = "http://www.blackboard.com/legal/terms-of-use.html",
+	44	title = "Terms Of Use"
+	45	}
+	46
+	47	@online{bb-privacy-policy,
+	48	title = "Blackboard Privacy Statement",
30	49	date = "2018-05-24",
31	50	url = "https://www.blackboard.com/legal/privacy-policy.html"
32	51	}
+	52
+	53	@article{bb-blackout,
+	54	url = "https://web.archive.org/web/20101115105111/http://blogs.palmbeachpost.com/extracredit/2008/04/18/blackboard-blackout/",
+	55	author = "Kim Miller",
+	56	title = "Blackboard Blackout",
+	57	date = "2008-04-18"
+	58	}
+	59
+	60	@article{bb-blackout2,
+	61	url = "https://web.archive.org/web/20110926094431/http://media.www.thehunterenvoy.com:80/media/storage/paper1327/news/2009/02/18/News/Portal.Problems.Blackboard.Blackout-3635795.shtml",
+	62	author = "Jonathan Jordan",
+	63	date = "2009-02-18",
+	64	title = "Portal Problems, Blackboard Blackout",
+	65	subtitle = "Data Systems at CUNY Malfunction and Disrupt Classes"
+	66	}
+	67
+	68	@article{bb-crash,
+	69	url = "http://itintheuniversity.blogspot.com/2007/11/in-recent-chronicle-article-outlining.html",
+	70	author = "Luke Fernandez",
+	71	title = "Blackboard catastrophic system crash in Utah",
+	72	date = "2007-11-27"
+	73	}
+	74
+	75	@article{bb-dataloss,
+	76	url = "http://bpeacock22.blogspot.com/2009/01/great-blackboard-crash-of-09.html",
+	77	title = "The Great Blackboard Crash of 09",
+	78	author = "Benjamin s.s.t.t.",
+	79	date = "2009-01-21"
+	80	}
+	81
+	82	@online{ufora,
+	83	url = "https://www.ugent.be/nl/actueel/lms-ufora.htm",
+	84	title = "De nieuwe Minerva heet Ufora",
+	85	author = "Universiteit Gent",
+	86	date = "2018-06-17"
+	87	}
+	88
+	89	@online{opleiding-informatica,
+	90	url = "https://www.uhasselt.be/documents/BROCHURES/2018-2019/Master-Informatica-2018-web.pdf",
+	91	title = "Master in de Informatica",
+	92	year = "2018",
+	93	author = "Universiteit Hasselt"
+	94	}
33	95

1	-	Joeni is op dit moment een kant-en-klare oplossing voor de problemen die
2	-	BlackBoard en het studentendossier stellen aan de UHasselt.
3	-
+	1	Joeni is op dit moment een voorbeeld van een kant-en-klare oplossing voor de problemen die
+	2	BlackBoard en het studentendossier stellen aan de UHasselt.
+	3
4	4	Maar software is steeds in beweging, en is nooit af. Daarom dat ik hier enkele
5	-	punten voorzie omtrent de toekomstige uitbreidingen die aan Joeni zouden kunnen
6	-	worden toegevoegd.
7	-
+	5	punten voorzie omtrent de toekomstige uitbreidingen die aan Joeni zouden kunnen
+	6	worden toegevoegd, of aan eender welk ander programma dat als vervanging zou dienen.[fn:still-joeni]
+	7
8	8	** /Desktop/-applicatie
9	-	Op dit moment wordt Joeni gebruikt via een webbrowser. Maar dit hoeft niet per
10	-	sé.
11	-	Een mooie (latere) uitbreiding voor Joeni, is dat de software uitgebreid wordt
12	-	met een applicatie die direct op de computers van de gebruikers kan werken.
13	-
+	9	gebruikt om "een vervangende applicatie" te beschrijven, alhoewel dit eender welk
+	10	ander programma kan zijn. Indien het specifiek om Joeni gaat, zal dit ook
+	11	duidelijk blijken uit de context.
+	12
14	13	Dit opent vanzelfsprekend mooie nieuwe toepassingen, zoals integratie met
15	-	/desktop features/ (zoals notificaties in de werkbalk), gemakkelijk door de
16	-	bestanden kunnen scrollen op een computer, verhoogde snelheid, dynamische
17	-	veranderingen in de interface, /direct messaging/ ...
18	-
+	14	Op dit moment wordt Joeni gebruikt via een webbrowser, maar dit is zeker niet
+	15	wat het eindpunt zou moeten zijn.
+	16
19	17	De data wordt natuurlijk vanaf de server gehaald (net zoals Joeni op dit moment
20	-	de data opvraagt). Hiervoor is geen aanpassing nodig aan de bestaande databank.
21	-
+	18	aan hun gebruikers bieden; ze zijn van nature statische tekstbestanden, die
+	19	enkel informatie kunnen doorsturen, en (gestructureerd) via speciale
+	20	HTML-formulieren informatie kunnen opvangen. Daar komen dan ook een hoop
+	21	beveiligingsproblemen bij kijken, die inherent zijn aan websites.
+	22
+	23	Joeni moet een programma worden dat op de computer zelf draait. Veel features
+	24	die nu simpelweg niet mogelijk zijn in Joeni, zouden hiermee wel mogelijk
+	25	worden:
+	26	- Pop-ups die aangeven als er een wijziging is gebeurd in het uurrooster :: Nu
+	27	moeten studenten zelf naar die webpagina surfen, er wordt geen proactieve
+	28	melding hiervan gemaakt. Veel agendaprogramma's geven hier ook geen melding
+	29	van, dus via iCal zal dit ook niet lukken.
+	30	- Live chat :: Dit is meer een feature die naar Agora toe gericht is, maar een
+	31	live chat is ook technisch niet mogelijk zonder /client-side
+	32	scripting/. Dit zou een uiterst handige toepassing zijn voor
+	33	groepswerken, waarvoor studenten nu nog altijd zijn aangewezen op
+	34	programma's van derden.
+	35	- Offline halen van studiemateriaal :: Het is triviaal, maar Joeni werkt enkel
+	36	met een internetverbinding, net zoals elke webapplicatie van de UHasselt.
+	37	Een "echt" programma kan al het studiemateriaal, meldingen, opdrachten, ...
+	38	downloaden op de computer van de student, zodat dit altijd offline
+	39	geraadpleegd kan worden. Het indienen van taken kan dan ook offline
+	40	gebeuren, waarna het programma zelf bij de eerstvolgende netwerkverbinding
+	41	de taak doorstuurt.
+	42	- Veel betere samenhang/snelheid :: Een webapplicatie impliceert dat alle pagina's
+	43	telkens opnieuw moeten worden ingeladen, er zit dus altijd een soort van
+	44	/delay/ tussen een klik van de gebruiker en de uiteindelijke reactie. De
+	45	browser moet ook alles inladen en /renderen/, dus een supersnelle cache
+	46	alleen zal nooit het snelheidsprobleem kunnen oplossen. En als de
+	47	verbinding wegvalt tijdens het inladen, dan is Joeni plots niet meer
+	48	bereikbaar, redelijk frustrerend. Een programma op de computer zelf heeft
+	49	al deze problemen niet. Er kan ook gebruik gemaakt worden van een hoop
+	50	andere /widgets/ (zoals tabs in hetzelfde venster) die de samenhang verder
+	51	kunnen verhogen.
+	52	- Dynamische/Directe informatie :: Als de gebruiker een fout maakt bij de
+	53	interactie met de website, dan kan hier pas melding van worden gemaakt als
+	54	de pagina opnieuw wordt ingeladen. Met een applicatie op de computer kunnen
+	55	direct meldingen worden gegeven, en kan het indienen onmogelijk worden
+	56	gemaakt totdat de gebruiker alle problemen heeft opgelost. Het geeft ook
+	57	zekerheid: Als een knop wordt ingedrukt, dan is er zekerheid dat de
+	58	verandering correct werd doorgevoerd.
+	59
+	60	De reden dat er voor Joeni toch gekozen is voor een webapplicatie om te
+	61	beginnen, is omdat het niet zozeer de bedoeling was dat Joeni "het eindpunt" zou
+	62	worden, maar eerder een voorstelling van hoe het eruit zou kunnen zien. Het zou
+	63	Joeni ook complexer maken: Rekening houden met dynamische veranderingen, pop-ups
+	64	inbouwen (waarvan de API's kunnen verschillen per besturingssysteem), ... Het
+	65	maakt het geheel veel moeilijker om te bouwen, maar voegt weinig toe voor deze bachelorproef.
+	66	Daarom dat een website het idee van Joeni veel beter overbrengt, maar dan wel in
+	67	een statische setting.\\
+	68	Daarbij is een groot deel van de code in de achtergrond (voornamelijk de
+	69	databasecode) overdraagbaar, daar een desktopapplicatie sowieso contact zal
+	70	moeten onderhouden met een databank.
+	71

1	1	Alle studenten beschikken over uurroosters die informatie verschaffen omtrent
2	2	hun weekplanning. Er zijn echter verschillende problemen met het huidige
3	3	systeem.
4	4
5	5	*** 3 verschillende systemen
6	6	In plaats van dat er één uurrooster is dat de meest relevante informatie
7	7	weergeeft, zijn er een hoop verschillende manieren om aan het rooster te
8	8	geraken.
9	9	**** Gewone uurroosters
10	10	Op [[collegeroosters.uhasselt.be][deze pagina]] moeten studenten hun faculteit
11	-	ingeven[fn:why-sit], daarop hun academiejaar, en dan het nummer van de week
+	11	ingeven[fn:why-sit], daarop hun academiejaar, en dan het nummer van de week
12	12	die ze willen inkijken. Daarop wordt een "interactieve" gif-afbeelding
13	13	ingeladen waarop de uren van een modeltraject worden weergegeven.
14	14
15	15	[fn:why-sit] Om een onbekende reden wordt de studierichting Informatica apart
16	16	geklasseerd onder de faculteit "SIT", maar dit is onjuist; deze studierichting
17	17	valt onder de faculteit Wetenschappen.
18	18
19	19	Dit systeem heeft verschillende problemen:
20	20	- Werkt niet zonder JavaScript :: Alhoewel dit makkelijk zonder JS kan werken,
21	21	werkt de website niet als scripts uitgeschakeld zijn. [[why-no-js][Dat vormt een probleem]].
22	-	- Weeknummers i.p.v. gewone data :: Ik ken geen mensen die bijhouden welke week
+	22	- Weeknummers i.p.v. gewone data :: Ik ken geen mensen die bijhouden welke week
23	23	van het jaar het is. We houden wel bij welke dag het is, en de meesten
24	24	plannen ook in op dagen.
25	25	- Opent niet automatisch op huidige week :: Veelal wordt het uurrooster gecheckt
26	26	omdat men wilt weten wat er deze week gebeurd.
27	27	- HTML én PDF :: Men kan zowel een HTML-pagina openen, als een PDF-bestand.
28	28	Waarom dat nodig is is niet geweten, maar het maakt de
29	29	achterliggende applicatie wel complexer om te onderhouden.
30	30	- Enkel modeltraject :: Veel studenten volgen een GIT-traject, maar zij moeten
31	31	met dit systeem vaak 2 á 3 keer opnieuw het proces doorlopen om
32	32	verschillende uurroosters zelf naast elkaar te leggen.
33	33	- Niet up-to-date :: Uit het onderzoek [LINK-NAAR-ONDERZOEK][bleek dat dit
34	-	uurrooster niet up-to-date is, en slechts 1 keer per dag wordt vernieuwd].
35	-	Zeker bij snelle wijzigigen voor bv. gastcolleges is dit uurrooster onbetrouwbaar.
+	34	[[Vergadering 1][bleek dat dit uurrooster niet up-to-date is, en slechts 1 keer per dag wordt vernieuwd]].
+	35	Zeker bij snelle wijzigigen voor bv. gastcolleges is dit uurrooster onbetrouwbaar.
36	36	Kleine opmerking bij het iCal-bestand dat op de pagina staat: Alhoewel de
37	37	iCal-specificatie velden specifieert voor locatie, wordt alle informatie over
38	38	een bepaalde gebeurtenis in de titel van het evenement geplaatst.
39	39	**** Dynamische uurroosters
40	40	[[https://uhintra03.uhasselt.be/uurroosters/][Deze uurroosters]] Zijn een directe verbetering op de [[Gewone uurroosters][gewone uurroosters]]; ze zijn
41	41	up-to-date, openen op de huidige week en geven slechts 1 resultaat (een
42	42	HTML-pagina). De resterende problemen blijven echter bestaan.
43	43	**** Uurrooster Studentendossier
44	44	Er is ook de mogelijkheid om een gepersonaliseerd uurrooster op te vragen
45	45	[[https://uhintra02.uhasselt.be/studdosst/sdsUurrooster.aspx][via het studentendossier]]. Deze geeft wél een GIT-traject, maar is nogal
46	46	omslachtig om te bereiken en ziet er erg gedateerd uit. Er is ook geen
47	47	mogelijkheid om een iCal-bestand te verkrijgen, dus voor de meest relevante
48	48	informatie moeten studenten steeds naar deze website surfen. Doordat het
49	49	JavaScript vereist is een simpele /web scraper/ schrijven ook niet echt triviaal
50	50	om te doen.
51	51	**** Nood aan eengemaakt systeem
52	52	Wat op dit moment bestaat is ontoereikend voor de vereisten van de studenten. De
53	53	systemen zijn omslachtig, complex en ze voelen gedateerd aan (en zijn dat ook).
54	54	Daarnaast is drie verschillende applicaties onderhouden sowieso gecompliceerder
55	55	dan maar ééñ onderhouden.
56	56
57	57	In Joeni wordt dan ook een eengemaakt uurrooster voorgesteld, dat poogt al deze
58	58	problemen op te lossen.
59	59

1	1	Alhoewel Joeni wel degelijk een positieve invloed kan hebben op de
2	2	IT-infrastructuur van UHasselt, zijn er nog steeds enkele punten die een
3	3	beperking kunnen opleveren. Deze punten worden in dit hoofdstuk toegelicht.
4	4	*** Algemeen
5	5	Joeni is niet volledig in het Nederlands. Sommige onderdelen worden wel in een
6	6	andere taal weergegeven dan Engels, maar deze zijn vaak automatisch via het
7	7	Django-framework vertaald (zoals de namen van dagen). Hier dient wel
8	8	genuanceerd te worden dat Blackboard eveneens niet in het Nederlands is. Voor
9	9	Joeni was meertalig zijn geen prioriteit, en dus is er meer aandacht besteedt
10	10	aan het maken van een volledig /functioneel/ programma, dan een volledig
11	11	/vertaald/ programma. Moest Joeni echter later ook ingezet worden binnen de
12	12	UHasselt, dan is vertalen in Nederlands, Frans, Duits, ... uiterst simpel: Alle
13	13	infrastructuur om te vertalen is al aanwezig in het Django-framework zelf. In
14	14	de code zijn alle te vertalen blokken ook gemarkeerd.
15	15	**** Missende pagina's
16	16	Niet alle pagina's zitten in Joeni en het is zeker niet mogelijk om direct Bb.
17	17	en Std. te vervangen. Er is hier ook een afweging gemaakt tussen complexiteit en
18	18	functionaliteit.\\
19	19	Tijdens het schrijven van Joeni werd snel duidelijk dat veel functionaliteit van
20	20	Std. verouderd is, en het herimplementeren zou dus nooit nodig zijn. Een goed
21	21	voorbeeld hiervan is de link naar het JOS-project van de VDAB[fn:jobteaser]: De link die op
22	22	het Std. te vinden is, wordt nu automatisch doorverwezen naar de hoofdpagina van
23	23	de VDAB. Sommige attesten op Std. worden ook uitgegeven door bepaalde diensten,
24	24	en daarvan kan natuurlijk niet op voorhand geweten zijn welke attesten.
25	25
26	26	Sommige pagina's konden gewoonweg niet gereproduceerd worden, omdat ze links
27	27	genereren naar bepaalde PDF-bestanden.
28	28
29	29	[fn:jobteaser] Op dit moment blijken de links naar het JOS-project offline
30	30	gehaald te zijn, en vervangen door een ander systeem genaamd "Jobteaser", maar
31	31	het is maar de vraag hoe lang deze links blijven staan.
32	32	*** Uurrooster
33	33	Het uurrooster biedt geen mogelijkheid om planning van andere richtingen in te kijken.
34	34	Ik vermoed niet dat dit iets is wat veel mensen zullen missen, maar dit
35	35	kan wel later worden toegevoegd als dit nodig blijkt te zijn. Joeni heeft dit
36	36	niet omdat het de bedoeling was om een zo simpel mogelijk systeem te ontwerpen
37	37	dat zoveel mogelijk mensen tegemoet komt. De mogelijkheid om planningen in te
38	38	kijken van andere studierichtingen is niet nuttig genoeg om te toevoeging ervan
39	39	te verantwoorden.
40	40
41	41	De vorm van de weergave van de week was een kritiekpunt op zich van een van de
42	42	testers; die merkte op dat de breedte van de verschillende dagen niet gelijk is.
43	43	Dit klopt ook: Dagen zonder "evenementen" worden dunner weergegeven dan dagen
44	44	waarop wel iets gebeurt. De argumentering hiervan is tweeledig: Enerzijds is het
45	45	logisch om belangrijkere zaken (een bezette dag) prominenter weer te geven dan
46	46	onbelange zaken (een vrije dag), en dat wordt bekomen door ze breder te maken.
47	47	Anderzijds vereist elke dag even breed maken extra opmaakcode.\\
48	48
49	49	*** Lokalen
50	50	Dit moet grotendeels worden ingevuld met recente informatie over de lokalen op
51	51	de UHasselt. Volgens Ines Boonen is er geen systeem informatie bijhoudt over de
52	52	lokalen, het is dus zeer waarschijnlijk dat de bestaande informatie dan ook niet
53	53	meer up-to-date is. Dit is natuurlijk gemakkelijk te remediëren door een dag de
54	54	universiteit rond te trekken en alle informatie te verzamelen.
55	55
56	56	Dit is op dit moment nog niet gedaan voor Joeni, omdat dit geen prioriteit was
57	57	van het project. Er zijn enkele voorbeeldlokalen ingevoerd om te laten zien dat
58	58	het systeem goed werkt en bruikbare informatie verschaft, maar langs alle
59	59	lokalen van de UHasselt gaan behoort niet tot de /scope/ van dit proefwerk.
60	60
61	61	*** Prikbord
62	62	Niet alle diensten die op het prikbord iets kunnen zetten, kunnen aangeven wie
63	63	een bepaald bericht kan zien. Tot nu toe kan enkel de examencommissie bepalen
64	64	wie een bericht mag zien, omdat de meeste van hun berichten toch gericht zijn
65	65	aan een enkele student.\\
66	66	Dit is nog niet geïmplementeerd omdat nog niet zeker is wat de meest
67	67	waarschijnlijke manier is dat informatie gedeeld wordt door de verschillende
68	68	diensten. Vermoedelijk zijn de meeste berichten toch bedoeld voor alle studenten
69	69	(getuige de PDF's die studeerruimte aanbieden), maar het kan natuurlijk dat
70	70	sommige berichten enkel aan een bepaalde studierichting getoond moeten worden.
71	71
72	72	*** Agora?
+	73	Nieuwe studenten kunnen zich via de website voorinschrijven op de UHasselt.
+	74	Alhoewel dit mooi geïntegreerd zou kunnen worden in Joeni, is er toch beslist
+	75	dit niet te doen.[fn:prereg-table]
+	76
+	77	Ten eerste is dit niet echt per sé nodig: Ook al vereist de voorinschrijving het
+	78	gebruik van /client side scripting/, het is niet zo doorgedreven als bij andere
+	79	onderdelen van de website. Daarnaast de pagina er esthetisch gezien nog goed
+	80	genoeg uit.\\
+	81	Ten tweede: Dit is een pagina waar haast alle studenten maar één keer in hun
+	82	hele leven mee in contact zullen komen. Om hiervoor een pagina toe te voegen aan
+	83	Joeni is nogal overbodig, er zijn namelijk tal van andere mogelijke
+	84	verbeteringen die veel vaker gebruikt zullen worden.
+	85	*** Agora?
73	86	Het originele project was groter dan wat Joeni op dit moment is; het eerste
74	87	voorstel omvatte ook een universitair communicatieplatform waarop studenten,
75	88	docenten en vakgroepen makkelijk met elkaar konden communiceren. Naast
76	89	Administratie en Vakken zou dit onderdeel Agora noemen.\\
77	90	Maar Agora staat in het menu doorgekrast. Uiteindelijk zit het niet in Joeni,
78	91	voornamelijk omwille van de grootte van het project, maar ook omdat het niet
79	92	direct tot een basistaak van de universiteit behoort.
80	93
+	94	De tabellen die Agora mogelijk maken zijn echter a
+	95
+	96	[fn:prereg-table] voor volledigheid van de databank is er wel een tabel
+	97	aangemaakt waarin de voorinschrijvingen kunnen worden opgeslagen, ~~PreRegistration~~.
+	98