NS-Consumenten zuil (casus)

De Nederlandse Spoorwegen vinden het erg belangrijk dat zij goed kunnen communiceren met hun klanten én van hun klanten goede of minder goede ervaringen horen. Daarom houden ze van tijd tot tijd een enquête onder de reizigers. Het nadeel van een enquête is dat het lang duurt voordat je de resultaten krijgt. De NS heeft gemerkt dat Twitter veel sneller werkt. Het lijkt de directie daarom een goed plan dat klanten hun opmerkingen/complimenten via een computer, aanwezig op elk het station, kunnen invoeren en dat deze opmerkingen dan zichtbaar worden in die stationshal.

De directie is echter ook wel een beetje bang voor Twitter, want men heeft gemerkt dat het ook gebruikt kan worden als uitlaatklep voor ontevreden reizigers. Daarom is het belangrijk dat de inhoud van de Tweets worden gelezen voordat ze worden gepost op Twitter en zichtbaar worden in de stationshal. Op deze manier kunnen respectloze uitingen en bijvoorbeeld schuttingstaal eruit gefilterd worden. Opdracht

De opdracht die jij krijg om dit uit te werken, luidt: ontwerp en bouw een systeem met behulp van Twitter waarbij de mening van klanten zichtbaar wordt voor andere reizigers.

Eisen voor het systeem

Om dit idee concreet te maken, denkt men aan de volgende systeemeisen (requirements):

1. Op een computerzuil (module 1) op een willekeurig NS-station kunnen mensen hun berichtje (hun Tweet) van maximaal 140 karakters invoeren. Dit bericht wordt in een database opgeslagen met de datum en een eventuele naam. Als deze leeg is wordt de naam "anoniem" ingevuld.
2. Daarna krijgt een moderator van de NS het berichtje te zien en diegene kan kiezen voor “accept” of “reject”. Bij “reject” wordt een opmerking samen met datum en tijd aan het bericht in de database toegevoegd. De moderator werkt eerst aan het oudste bericht. Bij de NS zijn verschillende moderators. We willen bij een bericht opslaan welke moderator het bericht heeft beoordeeld.
3. Bij “accept” wordt het berichtje op Twitter geplaatst via een twitteraccount. Het account bevat het woord “test” in de naam, want het gaat nu nog om een Proof-of-Concept (PoC).
4. Op een ander scherm worden een aantal van de meest recente Tweets van het account getoond in de stationshal (module 3). Het is belangrijk dat deze Tweets er goed uitzien.
5. Het kan zijn dat er tijdelijk geen Tweets geplaatst worden, bijvoorbeeld als niemand gedurende een bepaalde tijd een Tweet heeft geplaatst. Zorg ervoor dat je dan het weerbericht laat zien op het scherm in de stationshal (OPTIONEEL)
6. De moderator kan een overzicht kunnen krijgen van de afgekeurde Tweets in module 2 (OPTIONEEL)

Modules

Uiteindelijk zal je 3 modules en een database gebouwd hebben.

Eisen aan het ontwerp (en tips)

Het ontwerp omvat een BPMN-model en Use Case diagram met twee volledig uitgewerkte Use Cases. Daarnaast is een conceptueel datamodel vereist. Dit model wordt verder uitgewerkt in een logisch en fysiek datamodel. Tips voor de realisatie

Maak het bovengenoemde systeem met behulp van Python. Het gebruik van Tkinter kan mooie resultaten opleveren, maar is niet verplicht. Je mag ook gebruik maken van een andere Python GUI library. (mag dus ook een terminal applicatie zijn?)

Let op: de Twitter-API levert geen XML, maar JSON!

twitter_zuil (project)

3rd party libraries(dependencies)

Yes we're gonna use some libraries while I'm a minimalist, but the Oauth1.0a API twitter uses is just too much work to implement.

• TwitterAPI (by Geduldig, looks pretty maintained)
• requests (Kenneth Reitz, voor de OWM API)
• flask (voor de web backend)
• psycopg2

api keys

see api_keys.py a simple file with variables (not synced to git)

TWITTER_APIKEY TWITTER_APISECRET TWITTER_BEARER TWITTER_ACCESSTOKEN TWITTER_ACCESSSECRET OWM_KEY

API docs

• https://openweathermap.org/current
• https://developer.twitter.com/en/docs/twitter-api