width: 900 height: 900 maxScale: 1.5

SE-Tutorium 4 | Mittwoch 16 - 18 Uhr:

anchored to [[191.00_anchor]]

Lernziele:

  • Intuition zum Aufbau und Struktur von imperative shell functional core erhalten
    • nochmal im Code anschauen!
    • slides nochmal durchgehen und Verständnis sammeln ( vielleicht interaktiv!)
  • Konzept einer API verstehen / betrachten
    • API / Interfaces ?
    • was setzen wir bei einer API voraus / wie ist die Interaktion mit dieser?
    • Wo gibts APIs?
  • Interfaces
    • Anwendung / Verständnis
    • Interfaces programmieren / anwenden

Orga

  • Bildet Teams für HW6!
  • im Laufe der Woche Kontrolle von HW5
  • am Ende der Stunde gerne minute-paper durchführen –> immediate feedback!

Orga | HW5 Feedback |

[!Question] Gibt es Feedback zu HW5 ? -> gibt es etwas, was in der Aufgabenstellung/Formulierung/Umsetzung große Probleme bereitet hat?

  • Umfang in Ordnung?
  • bestimmte Probleme?

note: give them around 5 min at most ( ) Feedback: bei vielen Bioinfos : -> Concept eines Parsers Idee dazu, Meinung zu den (( Fokus der Verständnis kann teils schwierig sein))

Helpdesk wurde von einigen meiner Studis nicht wahrgenommen: -> Helpdesk ( Zeitlich schwierig) Freitag ungünstig, anderer Tag ware besser / von Vorteil

Ansatz zur Aufgabe setzen: -> + Scala als sehr neue Sprache Möglicher Ansatz: grobe Richtung, wie er aufgebaut werden kann, sollte gegeben / und aufgenommen werden.

| Imperative Shell | functional core |

–> revisit aus letztem Tutorium

| Imperative Shell | functional core |

[!Question] Konzept imperative shell <> functional core

-> Was streben wir mit dem Grundkonzept an? -> Was ist im functional core umgesetzt enthalten?

| Imperative Shell | functional core |

[!Question] Konzept imperative shell <> functional core -> Bedingungen für Interaktion von imperative shell und functional core?

[ Functional core ] | ]imperative shell[

  • Core Konzept: Aufteilen von Interaktion mit IO(imperative shell) und Verarbeitung von erhaltenen Werten (functional core)
  • imperative shell -> Interaktion mit I/O
  • functional core -> Arbeiten mit gegebenen Werten
    • functional core ist hierbei möglichst pure ( also Kontext-unabhängig funktionierend )

[ Functional core ] | ]imperative shell[

  • Wichtig: Shell darf Core aufrufen, aber Core darf nicht shell aufrufen!
  • core structure weiß quasi nichts von shell ( ist ja im eigenen Kontext aktiv)
  • Das heißt jetzt:
    • Bereich mit Ein und Ausgabe, welcher diese Dinge aufnimmt und anschließend
    • Verarbeitung an den funktionalen Core setzt -> dieser ist eventuell pure
    • also gleicher Input –> gleicher Output

praktische Umsetzung Imp-shell(IS) | (FC)func-core |

  • in EX7-tut4 gab es eine Aufgabe, wo das Prinzip geübt werden konnte
    • (haben wir zeitlich leider nicht geschafft)
  • –> kurz den Code gemeinsam betrachten ( link)
    • Wo könnte man das Prinzip umsetzen, warum?
    • (Vergleiche mit Beispiellösung von Jiri) (link)

note: open the old task and look around in the code ask what may be improved / should be improved -> requesting file directly

  • why bad? -> printing out directly
  • why could that pose problems?

praktische Umsetzung (IS) | (FC) | HW5

[!Task] Licenser aus HW5 und Implementation von IS / FC IM REPO:

  1. Finde Ordner /licenser aus HW5 (wieder)
  2. schau dir “Files.Scala” an
  3. Wo finden wir jetzt hier Functional core? | Imperative Shell ?
  4. welchen Vorteil hat die Verwendung hier?
  5. welchen Effekt möchten wir durch diese Implementation der Interfaces für File-Interaction beheben / bearbeiten ?

note: give them around 5 min to set up repo, then go over the file interactively!

\|/ weitere Fragen ? [no]\|/[yes]

note: to give insights on the concept of IS / FC or similar

API | Interfaces |

Interfaces |

  • Interfaces binden eine implementation von irgendetwas zu einem user-programm ( also etwas, was es anwendet)
  • anwende Instanz (user program) kann nur auf bereitgestellte Inhalte zugreifen
    • Interface gibt an, was / welche Funktionalität geteilt wird
    • Implementation ist nicht einsehbar vom user program
  • Beispiel: Funktions-Signatur:
  • gibt uns an, was rein / raus geht
  • nicht, wie es funktioniert!

Was ist ein Interface?

note: draw simple example:

user programm on the left on the right we have an implementation for website-crawler -> it can query all images, specific text blocks, search for a given block of text ( extract definition … ) where would we add / implement an interface now ?

Interfaces | Motivation | Modularity

  • Interfaces können als Bindeglied von Software-Komponenten in einem Programm dienen
    • KomponenteX brauch Interface –> what is required to run this?
    • KomponenteY gibt Interface –> what does it provide as service? (not how its done!)
  • bieten eine Modularität!

Interfaces | Motivation | Modularity

  • –> Modularität ermöglicht:
    • Komponente deckt einen Bereich ab
    • Änderungen an einer Stelle sollten andere nicht brechen ( da sie da nur via Interface abgerufen werden!)

Interfaces | Modularity

trait Interface {...} 
def component(required : Interface ) : Unit = ...
def anotherComponent(): Interface = ...

note: source für weiteres Beispiel eines Interfaces https://www.w3schools.com/java/java_interface.asp

Interfaces | Modularity

  • Key Advantage: Wir arbeiten quasi gegen eine Black-Box
    • Anfrage an interface gibt etwas zurück
    • wie die Implementation funktioniert, wissen wir nicht!
    • Implementation kann sich ändern ( ohne, dass wir es merken)

Interfaces | Modularity

Interface und Implementation von etwas sind strikt geteilt!

  • es folgen diverse Paradigmen / Konzepte: modular decomposability/understandability/continuity/…
  • –> hat also diverse Vorteile!

| API |

note: sources for further reading:

  • https://en.wikipedia.org/wiki/API
  • https://www.ibm.com/topics/api
  • https://www.ibm.com/topics/rest-apis

API - Application Programming Interface

  • spezifischer Typ eines Interfaces
  • ermöglicht es Programmen untereinander Daten austauschen zu können
  • –> also gedacht, dass sie von Programmen genutzt bzw von diesen implementiert werden ^
  • bieten Schnittstellen, um ihre Funktionalität abrufen zu können
    • bsp: give me cat-image for this number https://catnumber.test/?number=10
  • Implementation ist auch hier nicht zwingend verfügbar!

note: as a note for how we can differentiate between API / interface: interfaces are generally an abstraction -> some agreed-upon way of communicationg / exchanging information –> ok if you knock three times on the door I will shut down internally -> APIs könnten mehrere Interfaces beinhalten –> NUtzer*innen können verschieden darauf zugreifen!

API - Application Programming Interface

[!Question] War der Parser aus HW5 eine API ?

EXKURS >> REST API

  • REpresentational State Transfer
  • quasi-standard für Web-APIS
    • baut auf 6 Prinzipien auf, die beim bauen einer solchen API eingehalten werden sollten
  • 1. : Uniform Interface -> wie sollen die Daten erreicht werden ( GET/POST/PUT/DELETE Methoden für HTTP)
  • 2. : Client / Server -> API bildet also eine Schnittstelle zwischen User*in, die zugreifen und anfragen und Server, der verarbeitet und zurückgibt
  • 3. : Stateless –> Jede Anfrage muss ohne Vorwissen verständlich sein

EXKURS >> REST API

  • 4. : Cacheable –> Client sollte wissen, ob die Daten wiederverwendet werden können / oder nicht
  • 5. : Layered System –> eine Ebene im Programm darf nur mit ihrer nächsten ( die, die mit dem Interface angesprochen wird) kommunizieren
  • 6 : Code on demand -> optional

note: Weitere Quellen

  • https://www.ibm.com/topics/rest-apis
  • https://restfulapi.net/

API == Interface ?

note: ask them about it -> not necessarily because an API can have many interfaces to provide a functionality and they are usually looked at differently –> interfaces can be coded, apis are just used ( someone else codes them, we use its functionality!) -> Interfaces define abstract / generalized structures ( like a door: we know how to interact with them etc )

API | Übung |

[!Task] Aufgabe ( auch im Repo zu finden) In kleinen Gruppen:

  1. Go to https://http.cat/ and try 200, 404, 403, 418
  2. Describe the input, output and how they relate!
  3. Go to http://colormind.io/api-access/ and read the API description
  4. Based on the description, make predictions: what’s the input, what’s the output?
  5. Try it out both using curl and using the httpie online app
  6. Describe the endpoints precisely: what’s the inputs, what’s the outputs, how they relate. Verify your hypotheses by calling the API either with curl or the httpie online app.diese API funktioniert ( Was gibt sie aus, wenn man http.cat/status/nummer eingibt?)

note: have them work on that for around 10 min then we should compare those together!

#refactor #TODO use in next weeks tutorial –> to compensate and train it all once more //

Interface selbst programmieren | Übung |

[!Task] Aufgabe ( siehe REPO) IM REPO ( EX8-tut4 ):

  1. Betrachte die Beschreibung von “Tuetter” -> wie führt man es aus / startet es?
  2. Teste, wie beschrieben, das Programm aus
  3. Schau dir Aufgabe 3.1 an -> bei Fragen gerne melden!
  4. bearbeite die Aufgabe entsprechend :)
  5. wiederhole Steps 3,4 für die weiteren Aufgaben (3.2/3.3)

| Feedback | minute paper |

  • Hausaufgabe 6 nicht vergessen!

[!Task] 1 - Minute Paper ausfüllen Beantworte kurz die Fragen:

  • Dieses Thema / Bereich muss ich nach dem Tutorium nochmal anschauen
  • Haben mir die Aufgaben im Tutorium zum Verständnis beigetragen??
  • ist mir das Konzept von Interfaces klar geworden?
  • Habe ich dazu noch fragen ( welche?)