Implizite Informationen

Der eine oder andere weiß, dass ich an meinem iMac noch eine zweite Tastatur angeschlossen habe. Diese ist vielleicht nicht so gut, um Passwörter einzugeben, hilft aber beim Lernen von Blindschreiben.

Bisher vertrugen sich beide Tastaturen gut. Seit zwei Tagen muckt Das Keyboard aber herum: Apfel-Q funktioniert nicht bei allen Anwendungen und auf einmal sind die Tasten "<" und "^" vertauscht. Ich könnte mich daran gewöhnen, aber nur um den Preis eines Broken Window. Also besser ändern. Dabei meinte ich, mit dem Umstieg von Windows auf OSX solche Flausen hinter mir gelassen zu haben.

Eigentlich sollte das Einstellen ganz einfach sein: Systemeinstellungen >> Tastatur >> Tastaturtyp ändern ... Eigentlich. Tatsächlich war vom Button zum Ändern des Tastaturtyps keine Spur. Ganz wie beim vormals großen Bruder aus Redmond.

Tief in den Eingeweiden von OSX findet sich dann doch noch ein Lösungsweg: als Administrator die Datei /Library/Preferences/com.apple.keyboardtype.plist löschen (Ängstliche benennen diese Datei nur um) und das System neu starten. Nach dem Reboot wird versucht, Das Keyboard mit Hilfe eines "Assistenten" zu identifizieren. Funktioniert. Der Button erscheint auch wieder in den Systemeinstellungen. So etwas kenne ich doch auch von diesem anderen Betriebssystem. Na ja, es funktioniert und mit Linux wird in einigen Jahren sowieso alles besser.

Es gibt vier Probleme, wenn man einen Mailserver selbst betreiben möchte:

• der Server sollte dauernd erreichbar sein, damit er Mails auch entgegen nehmen kann,
• der Server sollte abgesichert sein und offensichtliche Spam-Mail erst gar nicht annehmen,
• andere Mailserver sollten dem Server "vertrauen", damit sie dessen Mails entgegen nehmen,
• der Server sollte regelmäßig über ein Backup gesichert werden, damit (wichtige) Mails nicht verloren gehen.

Der letzte Punkt ist einfacher zu realisieren, denn dies sollte sowieso für jeden Computer gemacht werden. Wer seine Daten nicht sichert, darf sich hinterher nicht beschweren. Ich empfehle, die eigenen Daten ohne viel Schnickschnack zu sichern. Aber das ist eine andere Geschichte.

Die ersten drei Punkte sind dagegen viel schwerer zu realisieren. Einen Server dauerhaft im Netz zu betreiben, gut und permanent zu administrieren, Sicherheitspatches einzuspielen, sich über die neuesten Tricks der Spammer auf dem Laufenden zu halten und dafür zu sorgen, dass der eigene Server eben nicht auf eine Blacklist kommt, das ist eine Aufgabe für fähige Administratoren. Ganz zu schweigen, dass man sich tiefergehend mit MTAs, MDAs, MUAs und ggf. MRAs auseinander setzen muss. Tiefergehend. Für mein Wochenendprojekt ist das definitiv zu viel.

Viel einfacher ist der in einem c't-Artikel besprochene Weg: mein Mailhoster kümmert sich um die ersten drei Punkte. Das macht er nämlich richtig gut. Alles, was ich noch tun muss ist:

• einen Mailaccount beim Mailhoster einrichten,
• die Mails regelmäßig abholen und auf den eigenen Server schieben (dafür ist der MRA notwendig, bei mir ist es getmail),
• einen lokalen MDA betreiben (ist bei mir procmail),
• für den Zugriff meines Mailprogrammes einen IMAP einrichten (bei mir: dovecot),
• dafür sorgen, dass der MTA (bei mir postfix) die Mails nicht direkt versendet, sondern den MTA des Mailhosters als Relais verwendet.

Das alles klingt schwieriger als es ist. Außerdem hat ein Wochenende zwei Tage und zwei Nächte ;-). Im Ernst, je nach verwendetem Betriebssystem (Windows bitte eher nicht) und / oder Distribution und / oder Hersteller des Serverleins gibt es schöne Anleitungen im Netz. Einfach mit der Suchmaschine der Wahl danach googeln.

Bei mir war die Sache mit dem MRA (getmail) etwas einfacher, da ich getmail schon für den Backup meines Kontos bei Google Mail verwendet habe. Das dort beschriebene entsprechend anpassen.

Das Einrichten von MDA (procmail) und IMAP (dovecot) war recht einfach, viel zu schrauben ist dort nicht. Trickreicher war höchstens, den MTA (postfix) zu überreden, die Mails nicht selbst auszuliefern, sondern den Mailhoster als Relais zu verwenden. (Nebenbei: bei meinen persönlichen Tests kamen alle Mails auch ohne Relaisfunktion an, bis auf die an meine Arbeit. Your mileage may vary.)

Den Aufruf von getmail steuere ich übrigens per cron. Zu meiner eigenen Entschleunigung fragt getmail nicht alle paar Minuten meinen Mailhoster auf neue Mails ab, sondern viel seltener. Aktuell experimentiere ich mit Zeitabständen von 2-3 Stunden. Sprich, ich kann soviel meinen lokalen IMAP-Server neue Mails prüfen lassen, die kommen eh erst alle 2-3 Stunden an. Wenn ich mich an die Zeitabstände gewöhnt habe (ja, dass muss ich), dann werde ich die Zeitabstände wochentags noch weiter verzögern: nur noch um 13 Uhr und um 17 Uhr. Wenn ich einmal eine Mail schneller benötige (z.B. zur Registrierung), kann ich den Abruf manuell starten oder den Webmail-Client meines Mailhosters nutzen.

Mit diesem Aufbau kann ich meine Mails im lokalen Netz sehr komfortabel abrufen. Für den mobilen Zugang muss ich meinen Router an zwei kleinen Stellen öffnen (IMAPS und SMTPS), mein Serverlein über einen DDNS-Dienst einen DNS-Namen geben (habe ich aus anderen Gründen sowieso) und einige Zertifikate für SSL erzeugen (habe ich auch schon).

Fertig.

Jetzt kann ich meine Mails auch mobil abrufen. Bisher nutzte ich auf meinem Händie zwei Mailprogramme: eines für die Arbeit und für Google Mail das von Google. Nun brauche ich nur noch eines. Sehr bequem.

Mein Konto bei Google Mail hat eine Weiterleitung auf meinen Mailhoster, seit Jahren nutze ich den Weiterleitungsdienst der ACM. Diesem muss ich meine neue Mailadresse mitteilen. So kommen alle Mails weiter an. Wer so etwas nicht hat, sollte nun allen die neue Mailadresse mitteilen.

Der Backup funktioniert?

Jetzt ist das erste Wochenende auch schon herum. Wer den Tatort verpasst hat, kann sich bei Twitter für das montägliche Teeküchengespräch beim Kaffeekochen noch schnell präparieren.

Beim nächsten Mal geht es um einen Ersatz für Google Reader.

Update 20.02.2012: die Gewöhnung an die Zeitabstände ging schneller als gedacht. Ab nun also nur noch wirklich um 13 Uhr und um 17 Uhr.

Als ich im letzten Blogeintrag darüber schrieb, wie man ein Backup für Google Mail anlegen kann, blieb bei mir tief im Inneren das Gefühl: da stimmt etwas nicht.

Google Mail ist ein sehr bequemer Dienst. Die Web-Oberfläche ist zwar nur einigermaßen komfortabel, aber ich habe mich mit einer Reihe von Labels und Filter dort gut eingerichtet. Spam ist kein großes Problem, dem Filter sei Dank. Für den mobilen Zugriff gibt es eine halbwegs vernünftige App. Zur Not ginge auch die Mobilansicht. Also was solls?

Ja, damals wollte ich weg von Google und habe es nicht geschafft. Den Anfang sollte Google Reader machen, aber nach einiger Zeit bin ich dann doch wieder zurück gekommen. Zu fehlerbehaftet war die Software (damals: Gregarius). Das lag sicher auch daran, dass ich nur über einen, hmm, eingeschränkten Webspace verfügte. Vom mobilen Zugang möchte ich gar nicht sprechen.

Heute ist vieles anders. Über meinen Hoster kann ich mich selbst nach knapp einem Jahr nun gar nicht beschweren. So gut wie alles ist dort möglich. Aber viel wichtiger: seit über 2 Jahren schnurrt ein kleines, linux-basiertes Serverlein unter meinem Schreibtisch. Dort hoste ich Daten, die besser auf meinen Systemen bleiben sollen (Klausuren, ...). Denn für jeden Rechner gilt: you must trust the admin. Nicht, dass ich Uberspace nicht über den Weg traue. Aber selbst unter Freunden gibt es Dinge, von denen der andere nichts wissen muss. Seit einem halben Jahr traue ich mich mein Serverlein nicht nur intern zu betreiben.

Irgendwann im letzten Jahr fing ich an, über meine eigenen Daten wieder nachzudenken. Mail, RSS-Feeds, Kalender, Kontaktdaten liegen teilweise in der Cloud. (BTW, immer wenn ich "Cloud" höre, fehlt mir das Objekt des Satzes). So 100%ig bin ich auch mit den ganzen sozialen Netzen nicht zufrieden. Weil es Twacbak gibt, nutze ich Twitter. Geplusst wird kaum und wenn, dann nur an bestimmte Kreise. Und Facebook? Da ist wohl wenig zu sagen. Wer sich dort austoben will, soll es tun. Oder ist noch nicht 18.

Den letzten Anschub gaben ein c't-Artikel und der Blogpost Why do self-respecting hackers use Gmail & Co?. Natürlich hätte ich einfach nur meine Mail bei Uberspace hosten lassen können. Aber zum einen lerne ich gerne dazu. In diesem Fall, wie man einen Mailserver aufsetzt und betreibt. Und zum anderen möchte ich meine Daten bei mir haben. Auf nicht von mir kontrollierten Systemen können gerne ggf. Kopien liegen. Aber meine Mail soll aufs Serverlein.

Womit ich die Titelzeile auflösen kann: Yoyod bedeutet "You Own Your Own Data". Das ist mein Motto für dieses Jahr. Ich weiß, damit bin ich spät dran. Aber besser als nie.

Nach dem Abschied von Google Mail steht der von Google Reader an. Passt sowieso zur Änderung der "Datenschutzerklärung" bei Google.

Als Ende Februar 2011 bei ca. 150.000 Nutzern von Google Mail die dort gespeicherten E-Mails gelöscht wurden, dachte ich erst einmal "Puh, zum Glück bin ich nicht betroffen". Aber will ich das weiter hoffen? In den ersten Tagen danach war das Web voll von klugen Ratschlägen, wie man ein Backup anlegen kann. Alle diese Methoden haben einen Nachteil: sie sind für Mausschubser graphische Oberflächen optimiert und müssen manuell gestartet werden.

Nichts für mich. Ich brauche einen Mechanismus, der im Hintergrund alles für mich automatisch erledigt. Idealerweise sogar auf meinem kleinen Serverlein. So werden E-Mails auch gesichert, wenn mein Hauptrechner ausgeschaltet ist.

Es gibt einige Anleitungen, wie man mittels Fetchmail an die E-Mails bei Google herankommt. Auf Grund einiger Inkompabilitäten funktioniert das Ganze wohl auch, aber das Problem ist ein anderes: was mache ich mit den frisch gelesenen E-Mails? Fetchmail ist darauf hin optimiert, die E-Mails an einen lokalen Mail-Server weiter zu leiten. Den wollte ich nicht auch noch aufsetzen.

Gestolpert bin ich dann über einen etwas älteren Blogeintrag How to back up your Gmail on Linux in four easy steps. Die dort angesprochene Software getmail realisiert genau das, was ich brauche: die frisch gelesenen E-Mails werden als normale Textdatei(en) gespeichert und können zur Not von üblichen Mail-Programmen eingelesen werden.

Das Problem mit dem Blogeintrag: er nutzt ein Übertragungsprotokoll, dass einige Beschränkungen aufweist: POP3. Zum einen beschränkt Google die Menge an übertragenen E-Mails, nach ca. 320 E-Mails ist Schluss. Zum anderen werden damit nur die empfangenen E-Mails abgeholt, nicht die E-Mails, die ich selbst geschrieben und gesendet habe.

Google Mail erlaubt zum Glück den Zugriff via IMAP. Wie auch POP3 muss IMAP innerhalb von Google Mail aktiviert werden. Bei den Einstellungen innerhalb von Google Mail auf den Punkt "Weiterleitung und POP/IMAP" klicken und dort "IMAP aktivieren". Alles andere in der Standardeinstellung belassen.

Der geneigte Nutzer von Google Mail weiß, dass unter dem Label "Alle Nachrichten" wirklich alle E-Mails zugreifbar sind, bis auf die im Spam-Ordner. Aber wer will die schon sichern? Bei einem Zugriff via IMAP werden die Label von Google Mail zu sogenannten Ordnern. Der Posteingang heißt unter IMAP "INBOX". Den IMAP-Namen für "Alle Nachrichten" konnte ich mittels Thunderbird als "[Gmail]/Alle Nachrichten" ermitteln. Bei einer anderen als der deutschen Spracheinstellung muss der Name entsprechend angepasst werden. Erinnert mich an das frühe VBA, als selbst die Befehle eingedeutscht waren. Schrecklich. Aber nicht zu ändern.

Mit diesen Daten ist alles zum Konfigurieren von getmail beisammen. Wie Sie getmail installieren müssen, werde ich nicht erklären. Das ist zu systemspezifisch. Auf meinem Serverlein reichte ein einfacher Aufruf des Paketmanagers.

Legen Sie als erstes in Ihrem Benutzerverzeichnis "~" das Verzeichnis .getmail so an, dass nur Sie darauf zugreifen können:

mkdir -m 0700 ~/.getmail

Dann legen Sie die Konfigurationdatei an. USER ist Ihr Benutzername bei Google Mail, PASSWORD Ihr Kennwort.

cat <<EOF > ~/.getmail/getmailrc
[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = USER@gmail.com
password = PASSWORD
mailboxes = ("[Gmail]/Alle Nachrichten", )

[destination]
type = Maildir
path = ~/.getmail/gmail-backup/

[options]
verbose = 0
delivered_to = false
received = false
read_all = false
message_log = ~/.getmail/gmail.log
EOF

Jetzt müssen Sie nur noch das Verzeichnis gmail-backup anlegen. Dies erledigt getmail leider nicht automatisch.

mkdir -m 0700 -p ~/.getmail/gmail-backup/{cur,new,tmp}

Jetzt kommt der große Moment:

getmail -g ~/.getmail -v -v -v

Mit diesem Aufruf starten Sie getmail (der konkrete Befehl kann, je nach Installation, ein wenig variieren). Die drei Optionen -v bewirken, dass Sie die Zugriffe auf Google Mail gut nachvollziehen können. Die ganz Harten unter uns können auch --trace verwenden. Nun wird der gesamte Inhalt Ihres Google Mail Kontos heruntergeladen und im Verzeichnis ~/.getmail/gmail-backup/new in einer Datei pro E-Mail gespeichert. Das kann dauern.

Inzwischen erkläre ich den Inhalt von getmailrc. Der Abschnitt [retriever] dürfte soweit klar sein. Hier geben Sie alle Informationen, um auf Ihr Google Mail Konto zugreifen zu können. Unter mailboxes geben Sie eine Liste der zu sichernden Labels an. Im Abschnitt [destination] wird definiert, wo und in welchen Format die E-Mails abgelegt werden. Ich habe mich für das Maildir-Format entschieden, da es gegenüber dem konkurrierenden mbox-Format wesentlich robuster ist. Und darauf kommt es mir bei einem Backup an. Wer möchte, kann die E-Mails in beiden Formaten speichern. getmail kennt dazu das Konzept MultiDestination.

Einige Einträge im Abschnitt [options] sind wichtig. read_all muss auf den Wert false gesetzt werden. Sonst liest getmail bei einem zweiten Aufruf alle E-Mails erneut ein und speichert diese mehrfach. delivered_to und received besitzen ebenfalls den Wert false, damit getmail die sog. Headerinformationen nicht ergänzt / ändert. Alle Vorgänge können in der unter message_log benannten Datei nachvollzogen werden.

Sind alle E-Mails inzwischen heruntergeladen worden? Nein? Dann ist ja noch etwas Zeit einen cron-Job einzurichten. Wieder ist dies von der jeweiligen Installation abhängig. Wichtig ist aber, beim Aufruf von getmail die Option -q anzugeben. Dann teilt getmail nur im Fehlerfalle etwas mit. Ich habe mir eine Datei angelegt, die ich dann im cron-Job verwende:

cat <<EOF > ~/bin/backup-gmail.sh
#!/bin/sh
/usr/bin/getmail -q -g /home/dkr/.getmail
EOF
chmod 700 ~/bin/backup-gmail.sh

Die Datei backup-gmail.sh lasse ich periodisch einmal am Tag aufrufen:

crontab -u dkr -l
50  23  *   *   *   /home/dkr/bin/backup-gmail.sh

Pünktlich um 23:50 Uhr läuft dann auf meinem Server die (inkrementelle) Datensicherung an. Bis jetzt ohne Probleme. Wer möchte, kann die nun lokal vorhandenen E-Mails auch noch woanders hin sichern. Sicher ist sicher.

Das Backup muss nicht per cron gestartet werden. Wenn Sie kein Serverlein besitzen, kann backup-gmail.sh auch ganz normal beim Anmelden gestartet werden. Nach dem ersten Backup, der naturgemäß länger dauert, braucht getmail auf meinem System ca. 3 Minuten für das Sichern der neu hinzugekommenen E-Mails. Davon wird die meiste Zeit mit dem Erkennen der neuen E-Mails verbracht. Bei mir sind es aktuell ca. 10.000 E-Mails, deren Header-Informationen gelesen werden müssen. Verschmerzbar.

Auf einen Nachteil möchte ich hinweisen: ungelesene E-Mails werden nach einem Backup als gelesen markiert. Dies ist vom Autor von getmail so gewollt, aber auch nicht wirklich schlimm. Der Backup kann nach dem Lesen der E-Mails gestartet werden. Oder ich schaue mir die E-Mails in der Reihenfolge ihres Eingangs unter "Alle Nachrichten" an. Fertig.

Die Projektstudie verlief in diesem Semester leicht anders. Während sich die Auswahl der Werkzeuge stabilisiert hat, rückten Aspekte, wie die von mir geforderte Aufgabenrotation in den Vordergrund. Nichts ist so beständig wie die Änderung.

Aufgabenrotation

Nach den Erfahrungen der letzten Semester hatte ich entschieden, dass alle Teilnehmer jede Rolle wenigstens einmal ausüben sollte. Nach meiner Beobachtung "versteckten" sich früher immer wieder Teilnehmer hinter ihren Rollen bzw. wurden auf diese abgeschoben. Auch stellten einige Studierenden vor der Projektstudie die Frage, ob es wahr sei, dass ein Projektleiter eine bessere Note erhält, als ein Entwickler.

(Die Projektleiter bekamen in der Vergangenheit tendenziell bessere Noten, weil sie sich mehr engagiert hatten und bessere Ergebnisse erzielten. Teilweise zwingt sie ihre Rolle dazu.)

In der Projektstudie gibt es die Rollen "Projektleiter", "Entwickler", "Dokumentar", "Qualitätsmanager". Jeder Teilnehmer soll jede Rolle wenigstens ein. zwei Wochen ausüben. So meine Entscheidung. Wann ein Rollenwechsel stattfindet, überließ ich den Projektteams. Zusätzlich soll jeder Teilnehmer mindestens zwei der wöchentlichen Statusreports verfassen.

In der Realität verursachte meine Entscheidung Probleme. Einige Teams hatten die Zeitpunkte und die Verteilung der Rollen nicht gut durchdacht. So war zum Beispiel ein Teammitglied zu Beginn Projektleiter und wechselte mit Beginn der Entwicklungsarbeiten in die Entwicklerrolle. Ein anderes Teammitglied machte es umgekehrt. Der Effekt: das erste Teammitglied hatte zu Beginn wegen der Planungstätigkeiten viel Arbeit, ebenso später als Entwickler. Das andere Teammitglied hatte zu Beginn als Entwickler wenig zu tun, ebenso nach Beginn der Entwicklungsarbeiten als Projektleiter.

In der Halbzeitretrospektive äußerten sich die Teilnehmer:

• Einarbeitung zu aufwendig
• Aufgabenrotation ist nicht notwendig, da Stellvertreterregelung gelebt wird
• Ungeplante Aufgaben durch zusätzliche Kommunikation / Übergabe
• Ungleiche Arbeitsverteilung

Aber auch:

• Aufgabenrotation fördert Kommunikation
• Rotation ideal nach einer Iteration

Nach der Halbzeitretrospektive entschied ich, dass es nur noch eine Aufgabenrotation geben soll. Jeder Entwickler soll mindestens 3 Wochen in einer anderen Rolle arbeiten und umgekehrt. Jeder Teilnehmer erstellt mindestens zwei der wöchentlichen Statusreports.

Die Abschlussretrospektive bestätigte diese Entscheidung, die im kommenden Semester Bestand haben wird.

Aufgabenverteilung

In der Halbzeitretrospektive deutete es sich an, dass viele Teilnehmer zu sehr in ihren jeweiligen Rollen lebten, ohne das gesamte Projekt im Blick zu haben. Daher kam die Anregung, dass die Teams zukünftig die Planung gemeinsam durchführen (bis auf ein, zwei Mitglieder, die sich hauptsächlich um die Entwicklungsumgebung kümmern) und dies nicht nur dem Projektleiter überlassen. Während der eigentlichen Entwicklungsphase übernehmen dann alle Teilnehmer Entwicklungsaufgaben, mit unterschiedlichen Schwerpunkten. Ein, zwei Teammitglieder kümmern sich auch um das Qualitätsmanagement, ein Teammitglied erstellt auch die nötige Dokumentation. Protokolle, o.ä. werden reihum erstellt. Der Projektleiter koordiniert ggf. die Aktivitäten, entwickelt aber auch.

Ich selbst halte dieses Modell für angemessen. Es bedeutet ein gehöriges Maß an Teamgeist von Anfang an. Deshalb werde ich es in Zukunft fördern, nicht erzwingen.

Lernziele

Schön fand ich es, dass die Teilnehmer zur Halbzeit- und zur Abschlussretrospektive viele der Lernziele für sich erfüllt sahen:

• Kennenlernen der Kommilitonen
• Kommunikationsfähigkeiten ausbauen
• Arbeiten im Team
• Zusammenhalt, gegenseitige Hilfe
• Fehlerbehebung, Arbeiten unter Stress
• Terminmanagement ist wichtig, sowohl das persönliche als auch für das Team
• Verantwortung übernehmen
• Anwendung der Programmierkenntnisse
• Kennenlernen praxisnaher Werkzeuge (Trac, Mercurial, Maven, Jenkins, Liferay, ...)

Einige Teilnehmer meinten, dass die Erfahrung in der Projektarbeit nützlich für jede Bewerung sein wird. Ich hoffe das.

Coaches

In diesem Semester gab es zwei Coaches: ein Coach für das Projektmanagement und ein Coach für technische Fragen. Liferay und die Entwicklung von Portlets war für viele etwas ungewohnt.

Die Entscheidung für zwei Coaches wurde von allen positiv aufgenommen. Sie waren gute Ansprechpartner und haben mit Rat (und nicht mit Tat, so soll es sein) den Teams weitergeholfen.

Auch von mir ein "Dankeschön" an E.K. und M.A.!

Frag-würdiges

Zwei Punkte sind für die Teilnehmer fragwürdig gewesen. Zuerst den der Teamzusammensetzung.

Ich setze die Teams nach dem Zufallsprinzip zusammen. Entweder mit einem Würfel oder mit einer kleinen Session in Python. Zur Halbzeitretrospektive wurde diese Entscheidung hinterfragt.

Nach Meinung der meisten Teilnehmer sollte in jedem Team mindestens ein "guter" Entwickler sein, der zugleich Ansprechpartner für "schwache" Entwickler ist. Zugleich soll er die Rolle eines "Chef-Entwicklers" ausüben und für die Architektur verantwortlich sein, sowie den Quellcode der anderen überprüfen. Alle Teams sollten in etwa gleich stark sein.

Gut fand ich den Gedanken eines Teilnehmers, ob alles auf die Entwickler "geschoben" werden soll. Zur Abschlussretrospektive kamen Fragen auf, wie man erkennen kann, dass jemand "gut" ist. Gute Noten in den Programmierveranstaltungen lassen nicht unbedingt auf gute Fähigkeiten schließen. Rückblickend war es für alle schwierig zu entscheiden, was die einzelnen Teammitglieder wirklich können. Das hat sich erst während der Projektarbeit herauskristallisiert.

Abschließend haben sich alle mit der zufälligen Verteilung auf die Teams anfreunden können, zumal sie so ihre "Soft Skills" verbessern konnten. Manche kannten sich vorher nicht so gut, wie zum Ende hin.

Den anderen "frag-würdigen" Punkt finde ich ebenfalls bemerkenswert: ein Team überlegte, welchen (wirtschaftlichen) Wert ihre Arbeit besitzt. Dieses Team führte eine Kostenanalyse durch. Schön, wenn die Teilnehmer so Kenntnisse aus den BWL-Fächern vertiefen.

Tipps

Zum Abschluss noch Tipps der Teilnehmer, meine Anmerkungen sind kursiv:

• Klare Zielsetzung schaffen, zur Not mehrfach nachfragen.
  • Oh, ja!
• Beim Aufbau des Wikis nicht unbedingt auf die Vorgänger vertrauen.
  • Kann ich nur unterstützen. Die Vorgänger könnten das eine oder andere falsch gemacht haben. Also trotz Kopieren das Nachdenken nicht vergessen.
• Einarbeitung in vorhandenen Programmcode ist schwieriger als ein komplett neues Projekt zu beginnen.
  • Kommt auf den Programmcode an...
• Codepräsentation frühzeitig durchführen.
  • Ich kann verstehen, dass man Unangenehmes vor sich herschiebt. Bei der Codepräsentation, das de facto ein (bewertetes) Review ist, erhalten Sie Hinweise zur Verbesserung. Das hilft Ihnen und Ihrem Projekt.
• Einarbeitung in Liferay ist nicht einfach.
  • Hmm, das sollte durch frühere Veranstaltungen abgedeckt sein. Laut Dozent wurde es auch behandelt. Haben Sie das Thema übersprungen / nicht näher studiert?
• Schon in den ersten Semestern kleinere Entwicklungsprojekte durchführen.
  • Wird von einigen Dozenten verstärkt durchgeführt. Evtl. hilft auch die geplante neue Version der SPO.

Falls ich etwas vergessen oder ungeschickt dargestellt habe, senden Sie eine E-Mail / DM an mich. Oder hinterlassen Sie einen Kommentar zu diesem Blogeintrag.