Yoko ist ein sehr schönes Theme für WordPress. Es passt sich automatisch der Fensterbreite bzw. dem Endgerät an („responsive layout“) und lässt sich somit nicht nur auf dem PC, sondern auch auf mobilen Endgeräten sehr gut betrachten.

Als Problem ergibt sich leider der Nachteil, dass bei einer mobilen Ansicht des WordPress-Theme Yoko das Menü nicht mehr aufgeklappt werden kann (Touch-Bedienung). Dies führt dazu, dass Unterseiten, die nicht direkt im Inhalt der Seite verlinkt sind, auf einem mobilen Endgerät nicht mehr zu finden sind.

Yoko um eine Unterseiten-Übersicht erweitern

Eine einfache und elegante Möglichkeit dieses Problem mit Yoko zu umgehen, ist die Erstellung eines WordPress-Seiten-Template, welches nach dem eigentlichen Seiten-Inhalt alle Unterseiten als Liste in einer Übersicht anzeigt. Dies ermöglicht eine erleichterte Bedienung des Themes und damit auch das problemlose mobile Navigieren durch die Webseite. Zunächst muss dazu das Theme Yoko selbst und danach der WordPress-Inhalt angepasst werden. Die Anpassung sollte maximal 20 Minuten in Anspruch nehmen (je nach Anzahl der umzustellenden Seiten).

Anpassung des Theme im Yoko-Theme-Ordner

Die beste Möglichkeit Yoko anzupassen, ist das Erstellen eines neuen Templates. Hierzu muss lediglich eine Datei namens „subpageindex.php“ im Yoko-Ordner (wp-content/themes/yoko) mit folgendem Inhalt erstellt werden:

<?php
/*
Template Name: Subpage index
*/
get_header(); ?>

<div id="wrap">
<div id="main">

    <div id="content">

        <?php the_post(); ?>

        <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>

            <header class="page-entry-header">
                <h1 class="entry-title"><?php the_title(); ?></h1>
            </header><!--end page-entry-hader-->

            <div class="single-entry-content">
                <?php the_content(); ?>
                <div class="clear"></div>
                <?php wp_link_pages( array( 'before' => '<div class="page-link">' . __( 'Pages:', 'yoko' ), 'after' => '</div>' ) ); ?>
                <?php edit_post_link( __( 'Edit →', 'yoko' ), '<span class="edit-link">', '</span>' ); ?>
            </div><!--end entry-content-->

            <!-- Subpage index -->
            <h2>Unterseiten</h2>
            <?php
            // Hier werden die direkten Unterseiten geladen
            $children = wp_list_pages('title_li=&depth=1&child_of='.$post->ID.'&echo=0');
            // Falls es Unterseiten gibt, werden diese ausgegeben
            if ($children) { ?>
                <ul>
                <?php echo $children; ?>
                </ul>
            <?php } ?>

        </article><!-- end post-<?php the_ID(); ?> -->

        <?php comments_template( '', true ); ?>

    </div><!-- end content -->

<?php get_sidebar(); ?>
<?php get_footer(); ?>

Der Inhalt dieser Datei gleicht dem Standard-Template einer normalen Seite (vgl. page.php), erweitert diese jedoch um eine Liste der direkten Unterseiten. Um die Unterseiten innerhalb des article-Tag einzubinden, wurde der Inhalt der Datei content-page.php mit eingebunden (Zeilen 14-37). Dieser würde sonst durch den Aufruf von

<?php get_template_part( 'content', 'page' ); ?>

nachgeladen.

Wichtig: Diese Änderungen werden, wie das Original-Theme Yoko auch, unter der GNU General Public License veröffentlicht.

Anpassung des Inhalts

Das erstellte Yoko-Template „Subpage index“ muss dann nur noch als Template der betroffenen Seiten eingestellt werden. Im WordPress-Adminpanel öffnet man die Seite, welche eine Übersicht der Unterseiten zeigen soll, zum Bearbeiten und wählt nun auf der rechten Seite unter „Template“ die Option „Subpage index“.

Ergebnis: Yoko mit einer Unterseiten-Übersicht

Auf einer Seite ohne eigentlichen Inhalt sieht das Ganze dann folgendermaßen aus:

Wer sich bei der Anpassung Arbeit sparen möchte, der kann sich die aktuellste Version des WordPress Theme Yoko auf GitHub forken.

Für Anregungen oder Tipps steht für euch wie immer die Kommentarfunktion bereit!

[](http://www.karllorey.de/wp-content/uploads/2012/04/hardwarepraktikum_robotik_roboter.png)

Da im Sommersemester 2012 an der Universität Würzburg wieder die Möglichkeit besteht, das Hardwarepraktikum in Robotik zu absolvieren und ich wiederholt nach meinen Erfahrungen im Hardwarepraktikum Robotik gefragt wurde, ist es wohl an der Zeit dies schriftlich festzuhalten.

Das Hardwarepraktikum an der Uni Würzburg

Jeder Informatik-Student muss während seines Studiums neben dem Java-Programmierpraktikum und dem Softwarepraktikum auch mindestens ein Hardwarepraktikum absolvieren. Es stehen hierbei drei verschiedene Praktika zur Auswahl:

Möglichkeiten ein Hardwarepraktikum an der Universität Würzburg zu absolvieren

• Hardwarepraktikum Prozessorbau (Kolla)
• Hardwarepraktikum Netzwerktechnik (Tran-Gia)
• Hardwarepraktikum Robotik (Busch)

Das Hardwarepraktikum Robotik ist nur während des Semesters und nicht in den Semesterferien zu absolvieren. Es wird von Stephan Busch betreut und findet in der Robotik-Halle hinter dem Informatik-Gebäude statt. Die Arbeit findet wie bei anderen Praktika im Team von zwei oder mehr Personen statt. Ich denke, dass man zudem zumindest die Rechenanlagen-Vorlesung besucht haben sollte.

Phasen des Hardwarepraktikum Robotik

1. Bau eines Grundgerüsts aus Fisher-Technik
2. Aufbau des Mikroprozessors sowie Anschluss und Kalibrierung der Sensoren
3. Implementierung von Lokalisation, Pfadverfolgung und anderen Features
4. Abschlussbesprechung mit Theorie-Fragen sowie Roboter-Test und -Präsentation.

Um meine Erfahrungen strukturiert und möglichst neutral zu halten, habe ich eine Liste mit positiven und negativen Punkten erstellt. Nichts desto trotz bleiben meine Eindrücke natürlich weiterhin subjektiv. Wir haben Stephan Busch unsere Erfahrungen nach Abschluss des Hardwarepraktikums sowohl schriftlich, als auch im Gespräch mitgeteilt.

Positiv

Eigenständiges Arbeiten

Die Arbeit am Roboter findet zu jeder Zeit im Team, jedoch ohne direkte Betreuung statt. Man arbeitet also völlig eigenständig, kann jedoch bei Bedarf Stephan Busch um Hilfe bitten. Die Einarbeitung in den Mikroprozessor findet per User Guide und Google statt.

Freie Zeiteinteilung

Dem Student steht es völlig frei, wann er sich um das Hardwarepraktikum Robotik kümmert. Einzige Voraussetzung ist, dass sich jemand in der Robotik-Halle befindet. Dies ist meistens ungefähr von 9 Uhr bis mindestens 18 Uhr der Fall. Wir haben als Zweier-Team über das Semester verteilt circa zehn Stunden pro Woche am Roboter gearbeitet.

Interessantes Thema

Wer baut nicht gerne einen Roboter? Im Vergleich zu den Hardwarepraktika Netzwerktechnik und Prozessorbau ist das Thema meines Erachtens ansprechend und praxisorientiert. Auch die Arbeit ist abwechslungsreich, da ständig zwischen Bau, Programmierung und Test gewechselt werden muss.

Sympathische Betreuung

Stephan Busch ist ein äußerst freundlicher, netter und ausgeglichener Betreuer. Dies sorgt er für ein wirklich sehr angenehmes Arbeitsklima.

Negativ

Fehlendes Feedback

Leider gibt es beim Hardwarepraktikum Robotik kein klares Feedback bis zur Abschlusspräsentation. Zwar existiert ein Trac (Projektmanagement-Software) in dem die einzelnen Zwischenschritte einzusehen sind, aber der Student erhält keine Rückmeldung darüber, wie gut seine Leistungen bisher sind. Die formulierten Milestones sind dafür zu knapp bzw. vage formuliert und natürlich statisch. Es fehlen aus meiner Sicht beispielsweise Zwischenprüfungen, aus denen hervorgeht, ob der Roboter bisher alles kann, oder ob von den Praktikumsteilnehmern nachgearbeitet werden muss. Da die Theorie auch eine größere Rolle als zunächst angenommen spielt, wären auch Tests zur Theorie wünschenswert.

Zu wenig Vorwissen als Informatiker

Für Informatiker gibt es wenig Möglichkeiten während des Informatik-Studiums schon Vorwissen anzusammeln. Gerade mit der Programmiersprache C oder etwas komplexeren Schaltungen wird man ins kalte Wasser geworfen. Dieses Vorwissen wird jedoch als Voraussetzung für das Hardwarepraktikum Robotik angesehen, weshalb während dem Praktikum keine oder wenig Zeit ist etwas nachzuholen.

Keine Möglichkeit der Heimarbeit

Mit dem Mikroprozessor/Roboter muss in der Robotik-Halle gearbeitet werden. Es ist nicht möglich den Prozessor mit nach Hause zu nehmen. Dies offensichtlich kein Fehler der Verantwortlichen, man sollte sich dessen trotzdem bewusst sein. Man kann also nur am Roboter arbeiten, wenn man auch in der Robotik-Halle ist. Die Arbeit muss also beendet werden, wenn in der Robotik-Halle die Tür geschlossen wird.

Keine Beachtung des Codes

Als Informatiker bemüht man sich meistens um einen sauberen und strukturierten Code. Dies war auch bei uns der Fall. Leider hatte Stephan Busch bei der Entscheidung, dass wir das Hardwarepraktikum Robotik bestehen, scheinbar noch zu keinem Zeitpunkt einen Blick auf unseren Quellcode geworfen, dessen Erstellung mindestens 60-70% der Arbeitszeit ausgemacht hat. Obwohl dies womöglich eine Lektion aus dem echten Leben ist, wo nur das Endprodukt zählt, empfinde ich dies bei einem Informatik-Praktikum (auch wenn es sich um Robotik handelt) doch als sehr enttäuschend und nicht verhältnismäßig. (Selbst wenn der Code ohne unser Beisein gesehen worden sein sollte, gab es zumindest zu keinem Zeitpunkt ein Feedback.)

Keine Berücksichtigung der Gruppengröße

Da beim Hardwarepraktikum Robotik die Gruppen selbst gewählt werden können, entstehen Gruppen von mindestens zwei und bis zu vier Personen. Beim Abschlussgespräch wurden wir als Zweier-Gruppe jedoch an den Leistungen der größeren Gruppen gemessen und somit keine Rücksicht auf die Gruppengröße genommen. Wir lagen als Zweier-Gruppe – was die Feature-Implementierung angeht – sicher nicht mehr als 10% im Vergleich zu anderen Vierergruppen zurück (bei halber Gruppengröße). Ich denke jedem ist klar, wie viel mehr eine Vierergruppe in einem Semester erreichen kann. Aus diesem Grund wäre eine Berücksichtigung der Gruppengröße durchaus angemessen gewesen.

Keine klar definierten Ziele und Organisationsmängel

Als großes Problem während des Hardwarepraktikums erwies sich immer wieder die Tatsache, dass sowohl uns, als auch anderen Teams nicht klar war, was eigentlich das Ziel zum Ende des Praktikums ist. Es war klar, dass der Roboter durch ein Labyrinth navigieren können muss, aber was implementiert sein muss und was nicht, war bis kurz vor Schluss völlig unklar (Muss-, Soll-, und Kann-Kriterien). Relativ früh hatte ein Team zum Beispiel einen Algorithmus entwickelt, wodurch ihr Roboter autonom aus dem Labyrinth finden konnte, allerdings ohne Lokalisation und Pfadverfolgung. Es stellte sich erst später heraus, dass Lokalisation und Pfadfindung zwingend implementiert sein müssen und das Herausfahren aus dem Labyrinth nicht als primäres Ziel, sondern eher als Bonus (wenn alles andere funktioniert) zu sehen ist.

Es wurde leider auch klar, dass Stephan Busch eine Liste (oder zumindest klare Vorstellungen) von dem hatte, was mindestens funktionieren können muss. Leider wurden diese Punkte weder herausgegeben, noch den Studenten zumindest mündlich (und rechtzeitig) mitgeteilt. Gerade der Sachverhalt, dass der zu implementierende Funktionsumfang scheinbar klar definiert, jedoch nicht klar genannt wurde, ist ein unnötiger Nachteil für Studenten und beeinträchtigt die Freude am Praktikum.

Auch in der Abschluss-Besprechung wurden plötzlich Theorie-Kenntnisse der Robotik gefragt, die während des Praktikums – wenn überhaupt – nur am äußersten Rand von Bedeutung waren. Es war bis dahin überhaupt nicht klar, dass bei dem Praktikum eine solche Auseinandersetzung mit der Theorie stattzufinden hat (Grad der Beweglichkeit, Interrupts auf Assembler-Ebene, u.v.m.). Es existierten zwar Fragen zur Selbsteinschätzung, diese waren aber bedeutend leichter als alles, was bei der Abschlusspräsentation gefragt wurde. Eine klare Angabe der nötigen Theorie-Kenntnisse oder detailliertere Fragen zur Selbsteinschätzung hätten hier sicherlich für mehr Klarheit gesorgt.

Ich möchte eindeutig darauf hinweisen, dass dieses Problem, wie die anderen Probleme auch, kein Problem der Machbarkeit, sondern nur eines der vorherigen Kommunikation und der Organisation des Praktikums ist:

• Natürlich kann man sich intensiv mit der Theorie befassen, aber das muss man das von vornherein wissen!
• Natürlich kann man sich besonders um ein bestimmtes Feature kümmern, aber auch das muss man von vornherein wissen und die Prioritäten kennen.

Fazit

Aufgrund der oben genannten, hauptsächlich organisatorischen Mängel kann ich das Hardwarepraktikum Robotik leider nicht empfehlen. Obwohl das Thema interessant ist, überwiegt nach einiger Zeit schnell die Frustration, die sich bis zum Schluss hält. Es fehlen klar definierte Ziele und angemessene Bewertungskriterien. Hier schneidet vor allem das Hardwarepraktikum Netzwerktechnik (Tran-Gia) mit wöchentlichen Bewertungen und begrenztem zeitlichen Rahmen im Vergleich deutlich besser ab. Auch vom Hardwarepraktikum Prozessorbau habe ich noch nichts schlechtes gehört, kann dazu aber auch nicht viel mehr sagen.

Falls sich jemand trotzdem entscheiden sollte das Hardwarepraktikum Robotik zu wählen, wäre ich für einen kleinen Bericht in den Kommentaren sehr dankbar. Auch gegenüber Kritik an meiner Sicht der Dinge bin ich offen.

Das Servicezentrum Forschung und Technologietransfer der Universität Würzburg bietet im kommenden Semester (Sommersemester 2012) eine Ringvorlesung zum Thema Unternehmerische Kompetenzen an. Die Vorlesung findet jeden Mittwoch von 18 bis 20 Uhr statt.

Aus der Vorlesungsbeschreibung zur Vorlesung „Unternehmerische Kompetenzen“:

Referenten aus Theorie und Praxis vermitteln anwendungsnah und mit viel Spaß am Thema Erfahrungen und Wissen. Die Studierenden erwerben Kenntnisse, die für eine eigene [Unternehmens-]Gründung wichtig, aber viel mehr noch in jeder zukünftigen abhängigen Beschäftigung unerlässlich sind.

Für die Vorlesung gibt es 3 ECTS-Punkte, die in den Schlüsselqualifikationen angerechnet werden können. Hierzu muss allerdings eine Klausur gegen Ende des Semesters (18.07.2012) geschrieben werden. Die einzelnen Vorträge der Vorlesung im Überblick:

• Idee & Potential

• Founders’ Corner

  (Vorstellung von Ausgründungen der Universität Würzburg) * Geschäftsplan-Erstellung I * Geschäftsplan-Erstellung II

  (inkl. Finanzierungsmodelle und Fördermöglichkeiten) * Unternehmensform & Recht * Marketing & Strategie * Projekt- und Zeitmanagement * Patente & Schutzrechte * Finanzmanagement * IT-Sicherheit & Social Media * Business Etikette & Interkulturelle Aspekte * Networking: Erfolgreiches Netzwerken!

Quelle

• Vorlesungsbeschreibung des SFT der Uni Würzburg
• Vorlesung im SB@HOME der Uni Würzburg

Vor kurzem wurden vom Institut für Informatik die Ergebnisse der Informatik-Vorlesungsumfragen des Wintersemesters 2011/2012 veröffentlicht. In den Vorlesungsumfragen werden den Studenten jedes Semester Fragen zur besuchten Vorlesung gestellt. Diese Fragebögen werden von der Universität Würzburg bzw. dem Institut für Informatik ausgewertet und in Form einer Tabelle veröffentlicht.

Da die Ergebnisse nur als unsortierte Tabelle veröffentlicht werden, was leider weder informativ noch aufschlussreich ist, habe ich mich entschlossen eine kleine Auswertung der Daten, inklusive Diagrammen und Bestenlisten, zu erstellen. (Disclaimer: Diese Daten beziehen sich nur auf das Wintersemester und berücksichtigen keine Vorlesungen des Sommersemesters)

Als Erstes folgt eine Auswertung der zehn besten Informatik-Vorlesungen, was wohl die interessanteste Kategorie für die meisten Informatik-Studenten dürfte. Soweit diese in den Studienverlauf und zum gewählten Fach passen, sollte wohl jeder Student bei Gelegenheit eine dieser Vorlesungen belegen.

Die zehn besten Informatik-Vorlesungen

1. Management im Software-Engineering (Schmied)
2. Neue Internet-Anwendungen – Technik und Modellierungsansätze (Tran-Gia/Hoßfeld)
3. Kryptographie und Datensicherheit (Glaßer)
4. Grundlagen der Zentralavionik (Montenegro)
5. Rechnernetze und Kommunikationssysteme (Tran-Gia)
6. Eingebettete Systeme (Kolla)
7. Informationsübertragung (Tran-Gia)
8. Einführung in Luft- und Raumfahrtsysteme I (Kayal)
9. Datenbanken 2 – Advanced Data Bases (Seipel)
10. Datenstrukturen und Algorithmen (Wolff)

Das Noten-Spektrum dieser Top 10 ist zwischen 1,4 für den ersten Platz und 2,3 für den zehnten Platz. Bemerkenswert ist meines Erachtens vor allem, dass Prof. Tran-Gia mit all seinen (in der Statistik berücksichtigten) Vorlesungen in den Top 10 der Informatik-Vorlesungen aus diesem Semester vertreten ist. Die bisher von mir besuchten Vorlesungen finden sich übrigens in meinem Studienverlauf Informatik an der Uni Würzburg.

Doch wo es gute Vorlesungen gibt, existieren leider auch nicht so gute Vorlesungen. Die folgenden fünf Vorlesungen wurden von den an der Umfrage teilnehmenden Studenten im Wintersemester 2011/2012 am schlechtesten bewertet (Noten von 1-6).

Die fünf am schlechtesten bewerteten Informatik-Vorlesungen

1. Einführung in die Informatik für Hörer aller Fakultäten

   (Note 3,6 – Gudenberg/Puppe/Seipel) 2. Entwurf und Analyse von Programmen

   (Note 3,6 – Gudenberg) 3. Luft- und Raumfahrtdynamik

   (Note 3,4 – Kayal) 4. Messtechnik

   (Note 3,2 – Rohmer) 5. Mathematik für Studierende der Luft- und Raumfahrtinformatik

   (Note 3,1 – Greiner/Lamprecht/Lechuga)

Hierbei ist natürlich der erste Platz die eigentlich schlechteste Platzierung mit einer Note von 3,6. Interessant ist, dass gleich zwei von drei Vorlesungen mit mehreren Dozenten unter den schlechtesten 5 Vorlesungen sind. (In Anbetracht der Notenskala von 1 bis 6, kann hier eigentlich nicht einmal von schlechten Vorlesungen, sondern nur von weniger guten Vorlesungen die Rede sein.)

Weitere Fakten

Da ein durchgehender Fließtext schlicht zu lange zum Lesen gewesen wäre, habe ich weitere interessante Fakten zur Informatik-Vorlesungsumfrage kurz zu einzelnen Absätzen zusammengefasst.

Die besten Dozenten

Zu den drei besten Dozenten (nach Schnitt aller Dozentenbewertungen auf einer Skala von 1-gut bis 5-schlecht) gehören laut Vorlesungsumfrage:

• Schmied (1,0)

  Management im Software-Engineering * Glaßer (1,4)

  Kryptographie und Datensicherheit * Tran-Gia (1,43)

  Informationsübertragung, Rechnernetze und Kommunikationssysteme, Neue Internet-Anwendungen * sowie Kolla und Montenegro (1,6)

Der höchste und der geringste Aufwand

Den meisten Aufwand benötigen mit Abstand:

• „Mathematik für Studierende der Luft- und Raumfahrtinformatik“ (Greiner/Lamprecht/Lechuga)
• und „Robotik – Robotics“ (Schilling)

mit jeweils ca. 18 und 17 Studen Aufwand pro Woche. Das sind knapp 50% einer 40-Stunden-Woche und sicher nicht die einzigen Vorlesungen eines Semesters, die ein Informatik-Student belegen muss.

Weniger als fünf Studen Aufwand reichen den meisten Informatik-Studenten scheinbar für folgende Vorlesungen:

• Entwurf und Analyse von Programmen (Gudenberg)
• Kryptographie und Datensicherheit (Glaßer)
• E-Learning (Puppe)
• Neue Internet-Anwendungen – Technik und Modellierungsansätze (Tran-Gia/Hoßfeld)

Die am seltensten besuchten Vorlesungen

Die Teilnehmer der Umfrage sollten beantworten, wie häufig sie die Vorlesung besuchen. Hieraus resultiert folgende Liste, welche die am seltensten besuchten Vorlesungen unter Informatik-Studenten darstellt. Hier finden sich natürlich auch einige schlecht besuchte Vorlesungen, da die Vorlesungszeit hier eingerechnet werden sollte.

1. Entwurf und Analyse von Programmen (31% – Gudenberg)
2. Eingebettete Systeme (53% – Kolla)
3. Logik für Informatiker (58% – Seipel)

Eine durchschnittliche Informatik-Vorlesung

Zum Schluss noch eine kleine Zusammenfassung der Vorlesungsumfrage anhand von Durchschnitten.

Die durchschnittliche Informatik-Vorlesung des durchschnittlichen Dozenten wird vom durchschnittlichen Studenten mit einer Häufigkeit von 75% und im vierten Semester besucht. Der Student findet die Vorlesung eigentlich gut (2,4), jedoch eindeutig schwieriger als andere (Informatik-)Vorlesungen. Auch den Dozent findet er zwar gut, den Übungsleiter allerdings eindeutig besser. Außerdem muss er pro Woche ca. neun Studen für die durchschnittliche Informatik-Vorlesung arbeiten.

Quelle

Die Vorlesungsumfrage der Universität Würzburg im Wintersemester 2011/2012 herausgegeben durch Prof. Puppe des Fachbereichs Informatik (wuecampus-Kurs zur Vorlesungsumfrage)

[](http://www.karllorey.de/wp-content/uploads/2012/02/SMS-Backup-Manager.jpg)

Die Veröffentlichung der ersten alpha-Version des SMS Backup Manager für SMS Backup & Restore wird sich leider noch etwas verzögern. Aus technischer Sicht ist die Version zwar soweit fertig, falls man dies von einer alpha-Version überhaupt sagen kann, es stehen aber leider noch einige organisatorische Probleme im Weg.

Ich habe mich dazu entschieden, den SMS Backup Manager unter einer Open Source Lizenz zu veröffentlichen, um so auch anderen die Möglichkeit zu geben, das Programm zu erweitern und verbessern. Hierzu muss ich aber noch eine Lizenz auswählen, was deutlich schwerer ist, als es sich vielleicht zunächst anhört. Außerdem habe ich deshalb geplant, das Projekt auf GitHub zu hosten, um Versionsverwaltung und Mitarbeit möglichst einfach und zugänglich zu gestalten.

Leider bleibt für diese Aufgaben neben dem Softwarepraktikum und den Klausurvorbereitungen nicht mehr viel Zeit übrig. Ich hoffe, ich finde dafür Anfang April genügend Zeit und muss die zahlreichen Google-Besucher nicht so lange warten lassen.

Vielen Dank für euer Verständnis!

Der Diffie-Hellman-Schlüsselaustausch ist ein Protokoll aus dem Bereich der Kryptografie. Mit ihm ist es möglich, sich über eine unsichere (also möglicherweise abgehörte) Verbindung auf einen geheimen Schlüssel zu einigen.

Wer sich mit den mathematischen Details des Diffie-Hellman-Schlüsselaustauschs etwas schwer tut, dem kann folgendes Video helfen die Vorgehensweise besser zu verstehen. Im Video wird der Diffie-Hellman-Schlüsselaustausch nämlich zunächst mittels Farben und erst anschließend mit Zahlen erklärt.

Das Video stammt aus dem YouTube-Channel ArtOfTheProblem, den ich wärmstens empfehlen kann! Wer sich anschließend doch mit den mathematischen Details befassen will, der wird natürlich bei der Wikipedia fündig.

Bereits seit einiger Zeit habe ich immer wieder auf der Website des Lehrstuhls für Informatik II an der Uni Würzburg nachgesehen und darauf gewartet, dass Informationen zum Softwarepraktikum in der vorlesungsfreien Zeit (den Semesterferien) veröffentlicht werden. Ich wollte das für mich dritte und letzte Praktikum neben dem Java-Programmierpraktikum und Hardwarepraktikum nämlich noch in den Semesterferien erledigen.

In der vergangenen Woche teilte mir dann ein Mitstudent mit, dass das Softwarepraktikum in den Semesterferien definitiv stattfinden würde, man sich jedoch selbst per Mail bei Prof. Puppe anmelden müsse. Da natürlich nicht jeder Interessierte diese Information mitbekommt, wenn sie nicht auf der Webseite des Lehrstuhls veröffentlicht wird, habe ich mich entschlossen die benötigten Informationen auch auf diesem Weg weiterzugeben.

Kurzinformation zum Softwarepraktikum

Beim Softwarepraktikum muss eigenständig in Gruppen ein Projekt erarbeitet werden, also alle Schritte von der Planung bis zur fertigen Software. Vorraussetzungen für das Praktikum sind die Vorlesungen:

• Algorithmen- und Datenstrukturen
• Softwaretechnik
• und das Java-Programmierpraktikum

Anmeldung zum SWP in den Semesterferien

Wer also auch in den Semesterferien noch sein Softwarepraktikum hinter sich bringen möchte, der hat noch bis Dienstag, den 14. Februar um 14 Uhr Zeit, sich bei Prof. Puppe anzumelden. Es winken 10 ECTS-Punkte.

Hier noch die Informationen aus der E-Mail:

Der Vorbesprechungs- und Starttermin zum Softwarepraktikum in der vorlesungsfreien Zeit wird am Dienstag, 14.2. um 14:00 stattfinden. Bitte kommen Sie zu dem Termin. Als Zeitaufwand für das Softwarepraktikum sind 300 Zeitstunden vorgesehen, dass entspricht bei einer Arbeitszeit von ca. 6 Stunden pro Tag etwa 50 Tage ( gut 7 Wochen), d.h. bis etwa Ostern. Die Abschlusspräsentation wird dann in der Woche vom 10.-13. April sein.

Anmerkung: Die Berechnung der Arbeitszeit inkludiert hier übrigens sowohl Samstage, als auch Sonntage. Wer ein freies Wochenende genießen will, muss nach dieser Aufwandsschätzung unter der Woche ca. 40 Stunden arbeiten, um in den Semsterferien fertig zu werden.

Mein Softwarepraktikum

Aus meinem Softwarepraktikum ist bisher ein Vorlage für ein LaTeX-Pflichtenheft hervorgegangen.