|
Size: 10358
Comment:
|
Size: 11784
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| DVA Praktikum für TI ==================== |
DVA Praktikum für TI (Gruppe Högl) ================================== Wintersemester 21/22 |
| Line 9: | Line 11: |
| | URL: http://elk.informatik.hs-augsburg.de/hhwiki/DVATI_Praktikum | | URL: http://hhoegl.informatik.hs-augsburg.de/hhwiki/DVATI_Praktikum | Moodle: https://moodle.hs-augsburg.de/course/view.php?id=5237 (Anmeldung, Ankündigungen, Forum) | Versuche: http://www.hs-augsburg.de/homes/hhoegl/dvati_versuche | Sphinx Demo-Bericht: http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht | Gitlab Repos der Teams: https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws21 .. | Versuchsbelegungsplan: https://cloud.hs-augsburg.de/apps/onlyoffice/84444846 |
| Line 14: | Line 24: |
| .. Ab dem Sommersemester 2010 betreue ich das DVA-Praktikum für die Technischen Informatiker (TI). |
|
| Line 21: | Line 28: |
| * sich mit wichtigen Themen aus der Technischen Informatik vertraut machen. Die technische Schwierigkeit steht dabei nicht im Vordergrund. Die Versuche werden eher leichte bis mittlere Anforderungen stellen, da die Bearbeitungszeit von einer bis zwei Wochen knapp ist. |
* sich mit wichtigen Themen aus der Technischen Informatik vertraut machen. |
| Line 31: | Line 35: |
| .. Der prinzipielle Ablauf ist identisch mit dem Ablauf bei den `Informatik-Versuchen <http://elk.informatik.hs-augsburg.de/hhwiki/DVAINF_Praktikum>`_. Nur die Details ändern sich: Eine Liste der Versuche finden Sie unter `<DVATI_Versuche>`_. Alle Studierenden werden wahrscheinlich in drei Gruppen eingeteilt. Jede Gruppe wird in etwa aus 16 Personen bestehen. Jede Gruppe wird aus mehreren Teams bestehen, jedes Team besteht aus drei bis vier Personen. |
Aus einer Themenliste werden Sie ein Semester lang alle ein bis zwei Wochen einen neuen Versuch bearbeiten. Insgesamt sind es fünf Versuche je Team. Die technische Schwierigkeit steht dabei wegen der kurzen Bearbeitungszeit nicht im Vordergrund. Die Versuche werden eher leichte bis mittlere Anforderungen stellen. Die Veranstaltung zählt mit 3 *Creditpoints*, das heisst der Arbeitswaufwand liegt in etwa bei 90 Stunden je Teammitglied. |
| Line 54: | Line 55: |
.. _bericht: Anleitung zur Abgabe der DVA Berichte ------------------------------------- Gilt nur für meine Gruppe. Bei den anderen Gruppen regelt das der eingeteilte Betreuer. 3. Oktober 2020 1. Alle Teams schreiben Ihren Bericht mit "Sphinx". Es gibt einen Demo-Bericht, den Sie hier finden: http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht Diesen sollen Sie lesen und an Ihre Gruppe anpassen, so dass ein leerer initialer Bericht entsteht. #. Diesen Bericht verwalten Sie auf Gitlab in Ihrem Repository für Ihr Team. Der Teamname besteht nur aus einer Zahl, z.B. 31, so dass sich dann der Link auf das Repository ergibt: https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws20/31 Nehmen Sie nur die Quelldateien in das Repository auf, *nicht* das Verzeichnis für die HTML Ausgabe ``_build/html/``! Jedes Repository soll eine Datei ``README.md`` enthalten, ein Muster sieht so aus: .. code-block:: text |
Ablauf ------ Die Studierenden werden in mehrere Teams eingeteilt, jedes Team umfasst zwei bis drei Personen. Jedes Team sucht sich einen Versuch aus einer Liste von Versuchen (`<DVATI_Versuche>`_) aus und bearbeitet ihn in der vorgegebenen Zeit (siehe Abschnitt Termine_). Jedes Team schreibt im Semester *einen* Bericht, der für jeden Versuch ein Kapitel enthält. Der Bericht wird mit `Sphinx <http://www.sphinx-doc.org>`_ geschrieben und in einem `Gitlab <https://r-n-d.informatik.hs-augsburg.de>`_ Repository fortlaufend aktualisiert. Der Bericht existiert *nur in elektronischer Form*. Auch die pro Versuch angefertigten Quelltexte werden in gitlab abgespeichert. In der **Bearbeitungszeit** des Versuchs arbeiten alle Team-Mitglieder zusammen. Typische Tätigkeiten sind Recherche, Planung, Hardware aufbauen, Programmierung, Fehlersuche, Test und Dokumentation. Sie können entweder ausserhalb der Hochschule oder im Labor G2.16 der Hochschule arbeiten. Der Raum ist täglich geöffnet von ca. 8:00 bis 17 Uhr. Die Zusammenarbeit aus der Ferne wird durch das Gitlab Versionskontrollsystem vereinfacht. .. figure:: http://hhoegl.informatik.hs-augsburg.de/dva/workflow/workflow1.png :width: 500 :align: center *Diese Menschen und Dienste sind beim DVA Praktikum beteiligt.* Die **Abgabe** erfolgt nach der ein- oder zweiwöchigen Bearbeitungszeit. .. Es ist unter Umständen nicht zwingend erforderlich, dass Sie bei der Abgabe persönlich anwesend sind, **die Anwesenheit kann jedoch von Ihren Betreuern jederzeit gefordert werden.** Eine Abgabe ohne Anwesenheit würde wie folgt ablaufen: Nach der Bearbeitungszeit befindet sich im Repository des Teams das entsprechende Versuchskapitel und alle sonstigen benötigten Dateien, Quelltexte, etc. Falls der Versuch vom Betreuer ohne Probleme aus dem Bericht nachvollzogen werden kann, und auch sonst alle Vorgaben erfüllt werden, dann kann der Versuch auch ohne Anwesenheit abgenommen werden. Dazu ist natürlich ein sehr gut geschriebener Bericht erforderlich. Verbesserungsvorschläge werden über Gitlab Issues an die Teams übermittelt. Auf diese Weise wäre es auch möglich, dass Studierende, die sich zu der Zeit nicht an der Hochschule aufhalten (z.B. Auslandssemester), am Praktikum teilnehmen können. Die Abgabe mit Anwesenheit findet im zuständigen Labor statt, z.B. G2.16. Bei der Abgabe hält das Projektteam einen kurzen Vortrag und zeigt eine Versuchsvorführung. Der Bericht kann dabei über einen Beamer an die Wand projeziert werden. In der Regel werden zur Vorführung und zum Bericht Verbesserungsvorschläge gemacht, die innerhalb der darauffolgenden Woche umgesetzt werden müssen. Bei einer zweiwöchigen Bearbeitungszeit kann der Zwischentermin für eine "Lagebesprechung" vor Ort im Labor oder virtuell über Videokonferenz genutzt werden. Jedes Team kann von den Betreuern dazu in die Labore eingeladen werden. Die Versuche werden je Team als **bestanden** oder **nicht bestanden** gewertet. Die Betreuer führen je Versuch und Team einen "Zustandsautomaten", der wie folgt funktioniert: .. figure:: http://hhoegl.informatik.hs-augsburg.de/dva/workflow/dvafsm.png :width: 350 :align: center *Der Zustandsautomat der Bewertung.* Jedes Team muss bei allen Versuchen den Zustand "bestanden" erreichen. Gitlab ------ Nach der Vorbesprechung lege ich die benötigte Anzahl Repositories auf Gitlab an und gebe über Moodle an alle Bescheid. Der *owner* der Repositories bin ich. Als *maintainer* wird ein Studierender pro Team ausgewählt, der dann selbständig die weiteren Teammitglieder einteilen kann. Die Repositories liegen alle unter dem Pfad https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws20/ In jedem Gitlab Repository liegt an oberster Stelle eine Datei ``README.md``. Der Inhalt wird im `Markdown <https://docs.gitlab.com/ee/user/markdown.html>`_ Format geschrieben. Gitlab zeigt den Inhalt dieser Datei schön formatiert an. Die Datei dient als erste Beschreibung, wenn jemand das Repository auswählt. Deshalb sollte in etwa der folgende Inhalt enthalten sein: .. code-block:: text |
| Line 104: | Line 140: |
| https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws19/XXX/ | https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws20/1 |
| Line 108: | Line 144: |
| Diese Datei ist in "Markdown" formatiert. Die Dokumentation für diese Formatierungssprache ist hier: https://github.github.com/gfm. Es wird *nur ein* Sphinx-Bericht abgegeben. Jeder Versuch, den Sie durchführen, ist ein Kapitel in diesem Bericht. #. Die HTML Ausgabe (``_build/html/``) soll auf den Webspace des Rechenzentrum hochgeladen werden. Wie das geht, steht im Demo-Bericht auf Kapitel 4.7 (Auf Webspace übertragen). Es genügt, wenn der Bericht in dem Web-Verzeichnis eines einzigen Gruppenmitglieds liegt und dieser URL in die README.md Datei aufgenommen wird. #. Hier ist ein Beispiel aus dem Sommersemester 2019 (DVA für Informatiker): * Gitlab https://r-n-d.informatik.hs-augsburg.de:8080/dva/berichte-2019/1 * RZ Home https://www.hs-augsburg.de/~brobot/dva |
Statt der \\-Zeichen kann man zum Zeilenumbruch auch zwei oder mehr Leerzeichen am Zeilenende verwenden. Der Bericht ----------- Einen Demo-Bericht finden Sie im HTML Format unter http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht. Im Bericht steht, wo der Quelltext des Berichtes auf gitlab liegt. Von dort können Sie ihn "klonen" und für Ihr Team anpassen. Gitlab und RZ-WWW ................. Der "Quelltext" des Berichtes liegt im Gitlab Repository. Nehmen Sie aber nur die Quelldateien in das Repository auf, *nicht* das Verzeichnis für die HTML Ausgabe ``_build/html/``! Die HTML Ausgabe wird erzeugt durch ``make html``. Die generierte HTML Ausgabe des Berichts (unter ``_build/html/``) soll in Ihrem RZ WWW-Verzeichnis gespeichert werden. Auf dem Rechner ``login.rz.hs-augsburg.de`` findet man dieses Verzeichnis in ``/www/<user>``, wobei ``<user>`` Ihr Login-Name ist. Dieses Verzeichnis finden Sie im WWW unter ``http://www.hs-augsburg.de/~user``. Sie finden diese Angaben auch im Demo-Bericht auf Kapitel 4.7 (*Auf Webspace übertragen*). Es genügt, wenn der Bericht in dem Web-Verzeichnis eines einzigen Teammitglieds liegt und dieser URL in die README.md Datei aufgenommen wird. .. Der Bericht kann bei Bedarf über Sphinx auch als PDF Datei ausgegeben werden ("make latex"). Diese Option ist ganz praktisch, wenn man einen Überblick bekommen möchte, wie viele Seiten man schon geschrieben hat. Ausserdem sieht man, ob die Grösse der Bilder im PDF Format stimmt. Wir brauchen die Berichte **nicht auf Papier** (ganz nach dem Logo "paperless"). Zum Inhalt .......... Der Bericht enthält für jeden durchgeführten Versuch ein Kapitel. Jedes Versuchskapitel sollte in etwa folgende Gliederung aufweisen: Datum, Thema 1. Einleitung Motivation, Aufgabenstellung 2. Grundlagen 3. Versuchsdurchführung Vorbereitung, Durchführung, Ergebnisse, Probleme 4. Zusammenfassung Fazit, Tipps für spätere Teams 5. Literaturangaben **Ganz wichtig:** Bei jedem Versuch muss nachvollziehbar sein, wer im Team welche Arbeit gemacht hat und welcher Zeitaufwand dafür in etwa nötig war! Der Bericht muss darüber Auskunft geben. Hier ist ein Beispiel-Bericht, der vom DVA Praktikum für Informatiker stammt: - Gitlab: https://r-n-d.informatik.hs-augsburg.de:8080/dva/berichte-2021/55 - RZ WWW Home: https://www.hs-augsburg.de/~mab-hsa/dva-praktikum/bericht/ Die Vorbereitungsaufgaben ------------------------- Die Vorbereitungsaufgaben dienen dazu, dass sich alle Teams an den Ablauf gewöhnen. Sie werden sich mit folgendem beschäftigen: - Mit Sphinx anfreunden (http://www.sphinx-doc.org/en/master/contents.html), siehe "Getting Started" - Mit Git und Gitlab anfreunden - http://hhoegl.informatik.hs-augsburg.de/hhwiki/GitSpicker - https://git-scm.com/doc - Freies "Pro Git" Buch in Deutsch https://git-scm.com/book/de/v2 - https://docs.gitlab.com/ce/ - Einloggen auf https://r-n-d.informatik.hs-augsburg.de, Beispiel-Repository anlegen, klonen, commit, push, pull, ... Das sollen alle Teammitglieder mit dem Beispiel-Repository testen, so dass Sie sich an die gemeinsame Arbeit in Gitlab gewöhnen. - ssh Schlüssel in gitlab anlegen (https://docs.gitlab.com/ce/ssh/README.html) - https://education.github.com/git-cheat-sheet-education.pdf - den Demobericht lesen und auf Ihr Team personalisieren und in Ihr Gitlab Repository aufnehmen - die HTML Ausgabe des Berichtes auf Ihr Web-Verzeichnis im RZ ablegen (das müssen Sie natürlich nach jeder Veränderung des Berichts wiederholen) |
| Line 129: | Line 237: |
| Termine (nur Mi) ---------------- XXX to do .. :: 1. 2.10.19, M1.01, 8:15 Vorbesprechung 2. 9.10.19, G2.16 Besprechung der Vorbereitungsaufgabe Ausgabe Versuch 1 3. 16.10.19, G2.16 4. 23.10.19, G2.16 5. 30.10.19, G2.16 6. 6.11.19, G2.16 7. 13.11.19, G2.16 8. 20.11.19, G2.16 9. 27.11.19, G2.16 10. 4.12.19, G2.16 11. 11.12.19, G2.16 12. 18.12.19, G2.16 .. _besserer-ablauf: Anregungen für einen besseren Ablauf ------------------------------------ H\. Hoegl, 21.11.2019 Planen Sie ihren Versuch so, dass nach einer Woche schon ein Teil des Berichtes in lesbarer Form im Gitlab Repository ist (also bis zum 27.11.). Dadurch kann man am 27.11. über mögliche Probleme beim Versuch reden. Der finale Versuchsbericht soll bereits am 4.12. fertig sein. Damit die Versuche variabler werden, bitte ich Sie, in den aktuellen Versuchen folgende Anregungen aufzunehmen: **GPS** (Team 31) GPS beschreiben, d.h. Funktionsprinzip, Beschreibung der Segmente, zu erreichende Genauigkeit. Auswertung der Rohdaten (NMEA-Sentences) durch Parsen -> Extraktion der Zeit und Position -> Bestimmen der aktuellen Geschwindigkeit Verwenden einer passenden Python-Bibliothek, die das Parsen schon übernimmt -> aus der gewonnenen Position die Entfernung zu einer nahen und auch einer weit entfernten Position bestimmen. **MBed** (Team 32) Das MBed Board bietet viel mehr Möglichkeiten als lediglich eine Ampelsteuerung mit drei LEDs zu programmieren. Dem Anschlussplan unter https://os.mbed.com/platforms/mbed-LPC1768 können Sie auch Analogeingänge, PWM-Ausgänge, Signale für eine Ethernet-Schnittstelle, eine SPI und eine I2C Schnittstelle entnehmen. Interessante Aufgaben sind z.B. das Ansprechen von Sensoren über I2C (z.B. Temperatursensoren oder WII Nunchuck Fernbedienungen - beide sind im Labor). Über PWM kann man z.B. Servos ansteuern. Die Signale SCL und SDA kann man mit Oszilloskop oder Saleae Logikanalysator ansehen. Man kann die Pull-Ups variieren und die Signalverläufe untersuchen. Welche Auswirkungen ergeben sich? Statt dem Online-Compiler kann man auch die Offline-Toolchain verwenden. Leistungsaufnahme: wie viel Strom benötigt ein das Board (evtl. verschiedene Betriebsmodi?) Wie lange würde Akkubetrieb rechnerisch klappen? **STM32 Nucleo Board** (Team 33) Dieses Board werden Sie auch im 5. Semester in *Embedded Systems II* verwenden. Deshalb ist die Zeit gut investiert, sich schon jetzt damit zu beschäftigen. Besorgen Sie sich von der CPU (STM32L476) das Reference Manual und verschaffen Sie sich einen Überblick über die Funktionsblöcke des Mikrocontrollers. Das STM32 Nucleo Board bietet ähnliche Möglichkeiten wie das MBed Board. Tatsächlich ist das Nucleo Board auch "MBed enabled", so dass man die MBed Programmierumgebung verwenden könnte. Es gibt allerdings noch einige andere Umgebungen, die sie ausprobieren können: * System Workbench for Linux https://www.openstm32.org/HomePage * STM32CubeIDE (= Atollic TrueStudio für STM32 + CubeMX) https://www.st.com/en/development-tools/stm32cubeide.html * Platformio https://docs.platformio.org/en/latest/platforms/ststm32.html * Micropython https://blog.boochow.com/micropython-firmware-for-mbed-boards Anregungen für Experimente sind z.B. das Auslesen des internen Temperatursensors oder das Einlesen von Analogwerten. Auch die Servo-Ansteuerung ist möglich. **RS485** Team 34) Untersuchen der Leitungen (A/B) mittels Oszilloskop. Beschreibung der Vorteile von RS485 gegenüber z.B. RS232. Ansprechen des seriellen Anschlusses mittels Python-Programm, z.B. Implementierung eines automatisch antwortenden Gegenstelle **RPi-HAT** (Team 35) Mindestens einer der Sensoren des Sense-Hats verwenden (Temperatur/Luftfeuchtigkeit/Luftdruck, IMU/Kompass) um z.B. ein Spiel *selbst zu implementieren* (die Spielidee darf es auch schon mal gegeben haben). Entwicklung eines Erbeben-Detektors mit Hilfe des IMU-Sensors -> kleine Messungenauigkeiten müssen gefiltert werden. Dazu sind kleine Experimente zur Filterung der Daten nötig. Bei einer entsprechenden Erschütterung soll das Display eine Warnung ausgeben. Entwicklung einer Wetterstation - mit Hilfe eines Frameworks oder einer selbst implementierten Lösung sollen Temperatur/Luftfeuchtigkeit/Luftdruck über einen längeren Zeitraum beobachtet werden können. Gerne auch mit Web-Interface oder unter Verwendung von MQTT und (freien) IoT-Diensten. **CAN** (Team 37) * Arbeiten Sie unter Linux mit socketcan. * Verwenden Sie zur Kommunikation mit dem CAN Bus sowohl ein Terminal-Programm als auch Software. Zur Auswahl stehen - Python (entweder https://pypi.org/project/python-can oder https://github.com/fishpepper/pyUSBtin) - Java * Sehen Sie sich die Daten auf dem CAN Bus mit einem Oszilloskop, mit dem Saleae Logikanalysator und mit Wireshark an. * Verwenden Sie den "USBtinViewer" (siehe https://www.fischl.de/usbtin). * Beschreiben Sie die Unterschiede zu RS-232 und RS-485. **Arduino** (Team 38) Messen von Analogwerten (beiliegender Poti). Ansprechen eines Servo-Motors. Entfernungsbestimmung mit Hilfe eines Ultraschall-Sensors. |
Termine ------- Oktober bis Dezember 2021, Dienstag, 14:00 - 15:30, G2.16 :: 1. 12.10. Ausgabe Versuch 1 Vorbereitungsaufgaben erledigen 19.10. 3. 26.10. Abgabe Versuch 1 Ausgabe Versuch 2 2.11. 4. 9.11. Abgabe Versuch 2 Ausgabe Versuch 3 16.11. 5. 23.11. Versuch 3 Ausgabe Versuch 4 30.11. 6. 7.12. Versuch 4 Ausgabe Versuch 5 14.12. 7. 21.12. Abgabe Versuch 5 |
DVA Praktikum für TI (Gruppe Högl)
Wintersemester 21/22
Inhalt
Willkommen zum DVA Praktikum für Technische Informatiker. Die Veranstaltung soll dazu dienen, dass Sie ...
- sich mit wichtigen Themen aus der Technischen Informatik vertraut machen.
- verständlich über die Themen reden können, daher wird es eine wöchentliche Kommunikation mit dem Betreuer geben.
- das, was Sie gelernt haben, auch in einem Bericht niederschreiben.
Aus einer Themenliste werden Sie ein Semester lang alle ein bis zwei Wochen einen neuen Versuch bearbeiten. Insgesamt sind es fünf Versuche je Team. Die technische Schwierigkeit steht dabei wegen der kurzen Bearbeitungszeit nicht im Vordergrund. Die Versuche werden eher leichte bis mittlere Anforderungen stellen.
Die Veranstaltung zählt mit 3 Creditpoints, das heisst der Arbeitswaufwand liegt in etwa bei 90 Stunden je Teammitglied.
1 Ablauf
Die Studierenden werden in mehrere Teams eingeteilt, jedes Team umfasst zwei bis drei Personen.
Jedes Team sucht sich einen Versuch aus einer Liste von Versuchen (DVATI_Versuche) aus und bearbeitet ihn in der vorgegebenen Zeit (siehe Abschnitt Termine). Jedes Team schreibt im Semester einen Bericht, der für jeden Versuch ein Kapitel enthält. Der Bericht wird mit Sphinx geschrieben und in einem Gitlab Repository fortlaufend aktualisiert. Der Bericht existiert nur in elektronischer Form. Auch die pro Versuch angefertigten Quelltexte werden in gitlab abgespeichert.
In der Bearbeitungszeit des Versuchs arbeiten alle Team-Mitglieder zusammen. Typische Tätigkeiten sind Recherche, Planung, Hardware aufbauen, Programmierung, Fehlersuche, Test und Dokumentation. Sie können entweder ausserhalb der Hochschule oder im Labor G2.16 der Hochschule arbeiten. Der Raum ist täglich geöffnet von ca. 8:00 bis 17 Uhr. Die Zusammenarbeit aus der Ferne wird durch das Gitlab Versionskontrollsystem vereinfacht.
Diese Menschen und Dienste sind beim DVA Praktikum beteiligt.
Die Abgabe erfolgt nach der ein- oder zweiwöchigen Bearbeitungszeit.
Die Abgabe mit Anwesenheit findet im zuständigen Labor statt, z.B. G2.16. Bei der Abgabe hält das Projektteam einen kurzen Vortrag und zeigt eine Versuchsvorführung. Der Bericht kann dabei über einen Beamer an die Wand projeziert werden. In der Regel werden zur Vorführung und zum Bericht Verbesserungsvorschläge gemacht, die innerhalb der darauffolgenden Woche umgesetzt werden müssen.
Bei einer zweiwöchigen Bearbeitungszeit kann der Zwischentermin für eine "Lagebesprechung" vor Ort im Labor oder virtuell über Videokonferenz genutzt werden. Jedes Team kann von den Betreuern dazu in die Labore eingeladen werden.
Die Versuche werden je Team als bestanden oder nicht bestanden gewertet. Die Betreuer führen je Versuch und Team einen "Zustandsautomaten", der wie folgt funktioniert:
Der Zustandsautomat der Bewertung.
Jedes Team muss bei allen Versuchen den Zustand "bestanden" erreichen.
2 Gitlab
Nach der Vorbesprechung lege ich die benötigte Anzahl Repositories auf Gitlab an und gebe über Moodle an alle Bescheid. Der owner der Repositories bin ich. Als maintainer wird ein Studierender pro Team ausgewählt, der dann selbständig die weiteren Teammitglieder einteilen kann. Die Repositories liegen alle unter dem Pfad
https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws20/
In jedem Gitlab Repository liegt an oberster Stelle eine Datei README.md. Der Inhalt wird im Markdown Format geschrieben. Gitlab zeigt den Inhalt dieser Datei schön formatiert an. Die Datei dient als erste Beschreibung, wenn jemand das Repository auswählt. Deshalb sollte in etwa der folgende Inhalt enthalten sein:
# DVA Praktikum für Technische Informatiker Hochschule Augsburg \ Fakultät für Informatik \ Wintersemester 2020/2021 \ Prof. Dr. Hubert Högl **Gruppe: 1** <!-- Nr Name MatrNr Studiengang+Sem, E-mail --> 1. Hans Maier, #123456, INF6, <Hans.Maier@hs-augsburg.de> 2. Anna Huber, #126987, INF6, <Anna.Huber@hs-augsburg.de> 3. Franz Xaver, #349816, INF8, <Franz.Xaver@hs-augsburg.de> 4. Isolde Weber, #432190, INF8, <Isolde.Weber@hs-augsburg.de> Das Gitlab Repository dieses Berichts ist unter https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws20/1 Der Bericht im HTML Format liegt hier: http://www.hs-augsburg.de/~xxx/xxx.
Statt der \-Zeichen kann man zum Zeilenumbruch auch zwei oder mehr Leerzeichen am Zeilenende verwenden.
3 Der Bericht
Einen Demo-Bericht finden Sie im HTML Format unter http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht.
Im Bericht steht, wo der Quelltext des Berichtes auf gitlab liegt. Von dort können Sie ihn "klonen" und für Ihr Team anpassen.
3.1 Gitlab und RZ-WWW
Der "Quelltext" des Berichtes liegt im Gitlab Repository. Nehmen Sie aber nur die Quelldateien in das Repository auf, nicht das Verzeichnis für die HTML Ausgabe _build/html/! Die HTML Ausgabe wird erzeugt durch make html.
Die generierte HTML Ausgabe des Berichts (unter _build/html/) soll in Ihrem RZ WWW-Verzeichnis gespeichert werden. Auf dem Rechner login.rz.hs-augsburg.de findet man dieses Verzeichnis in /www/<user>, wobei <user> Ihr Login-Name ist. Dieses Verzeichnis finden Sie im WWW unter http://www.hs-augsburg.de/~user. Sie finden diese Angaben auch im Demo-Bericht auf Kapitel 4.7 (Auf Webspace übertragen). Es genügt, wenn der Bericht in dem Web-Verzeichnis eines einzigen Teammitglieds liegt und dieser URL in die README.md Datei aufgenommen wird.
3.2 Zum Inhalt
Der Bericht enthält für jeden durchgeführten Versuch ein Kapitel. Jedes Versuchskapitel sollte in etwa folgende Gliederung aufweisen:
Datum, Thema
Einleitung
Motivation, Aufgabenstellung
- Grundlagen
Versuchsdurchführung
Vorbereitung, Durchführung, Ergebnisse, Probleme
Zusammenfassung
Fazit, Tipps für spätere Teams
- Literaturangaben
Ganz wichtig: Bei jedem Versuch muss nachvollziehbar sein, wer im Team welche Arbeit gemacht hat und welcher Zeitaufwand dafür in etwa nötig war! Der Bericht muss darüber Auskunft geben.
Hier ist ein Beispiel-Bericht, der vom DVA Praktikum für Informatiker stammt:
4 Die Vorbereitungsaufgaben
Die Vorbereitungsaufgaben dienen dazu, dass sich alle Teams an den Ablauf gewöhnen. Sie werden sich mit folgendem beschäftigen:
- Mit Sphinx anfreunden (http://www.sphinx-doc.org/en/master/contents.html), siehe "Getting Started"
- Mit Git und Gitlab anfreunden
- http://hhoegl.informatik.hs-augsburg.de/hhwiki/GitSpicker
- https://git-scm.com/doc
- Freies "Pro Git" Buch in Deutsch https://git-scm.com/book/de/v2
- https://docs.gitlab.com/ce/
- Einloggen auf https://r-n-d.informatik.hs-augsburg.de, Beispiel-Repository anlegen, klonen, commit, push, pull, ... Das sollen alle Teammitglieder mit dem Beispiel-Repository testen, so dass Sie sich an die gemeinsame Arbeit in Gitlab gewöhnen.
- ssh Schlüssel in gitlab anlegen (https://docs.gitlab.com/ce/ssh/README.html)
- https://education.github.com/git-cheat-sheet-education.pdf
- den Demobericht lesen und auf Ihr Team personalisieren und in Ihr Gitlab Repository aufnehmen
- die HTML Ausgabe des Berichtes auf Ihr Web-Verzeichnis im RZ ablegen (das müssen Sie natürlich nach jeder Veränderung des Berichts wiederholen)
5 Termine
Oktober bis Dezember 2021, Dienstag, 14:00 - 15:30, G2.16
1. 12.10.
Ausgabe Versuch 1
Vorbereitungsaufgaben erledigen
19.10.
3. 26.10.
Abgabe Versuch 1
Ausgabe Versuch 2
2.11.
4. 9.11.
Abgabe Versuch 2
Ausgabe Versuch 3
16.11.
5. 23.11.
Versuch 3
Ausgabe Versuch 4
30.11.
6. 7.12.
Versuch 4
Ausgabe Versuch 5
14.12.
7. 21.12.
Abgabe Versuch 5