Agile Webentwicklung: Tag 1
Universität Bremen 2012-03-05
Carsten Bormann
cabo@tzi.org
Ziel für Tag 1
- Gruppenbildung abschließen
- Infrastruktur aufbauen und austesten
- Alle können ordentlich arbeiten
- Jede Gruppe hat ihren Rhythmus gefunden
- Gemeinsame Infrastruktur: Wiki etc.
- Jede Gruppe bearbeitet ein Miniprojekt
- Nur heute
- Alle bearbeiten die gleiche Aufgabe
- Tag 2: Zuweisung der wirklichen Projekte
Voraussetzungen für Tag 1
- Alle haben alle drei Vorbereitungstermine wahrgenommen
- anwesend oder nachbearbeitet
- Aufgaben erledigt
- railstutorial bearbeitet
- Alle haben wirklich vor, diese Veranstaltung durchzuziehen
- Aussteigen mittendrin trifft den Gruppenpartner
- Heute ist Tag der Entscheidung
- (Modulanmeldung am Freitag/Montag)
Ablauf Tag 1 (1)
- 09:15 bis 11:30 (Pause in der Mitte)
- Einführende Worte (cabo)
- Vorstellungsrunde, die zweite
- Mehr von cabo
- Gruppenbildung abschließen
- repos aufsetzen etc.
- 11:30 bis 12:30 Mittagspause
- 12:30 bis 17:00
- Gruppenarbeit
- Evtl. Vorgespräche Projektzuteilung
Ablauf Tag 1 (2)
- 17:00 bis 18:00
- Bestandsaufnahme
- Gruppenbildung evtl. noch mal zurechtruckeln
- 18:00 bis 21:00
- Miniprojekt “fertig schreiben”
- Alle Zeiten sind virtuell
Umfrage, Vorstellungsrunde
- Umfrage
- Voraussetzungen: FB3-ID, Laptop, ...
- Erfahrungen vorbereitende Übungsaufgaben
- Arbeitsumgebung
- Versionskontrolle
- Vorstellung
- Name, Background
- Vorerfahrungen mit Web? Rails?
- Besondere Interessen?
- Open-Source
- soziales Engagement
- ...
Arbeiten an Software
Entwicklung von Websites und Softwareprojekten;
typische Anforderungen:
- Verwaltung vieler zusammengehörender Dateien
- Website:
- HTML-Dateien, Bilder, Style-Sheets, Java-Applets usw.
- Werden schrittweise weiterentwickelt, erweitert usw.
- Verschiedene Versionen, verschiedene „Releases“
- Verwaltung von Konfigurationen
- Welche Dateien müssen wie verarbeitet werden
- Verschiedene Konfigurationen möglich
- Gruppenarbeit
- Paralleles Arbeiten mehrerer Entwickler
- Auf verschiedenen Systemen, geographisch verteilt
Versionskontrolle
- Verfolgen von Änderungen
- Was habe ich wann geändert?
- Zugriff auf ältere Versionen
- Letzte Änderung war doch nicht so gut – alles zurück!
- Ich brauche mal eben die Version vom 1.4.2005
- Beziehungen zwischen Dateien
- Welche Versionen welcher Dateien gehören zur Freigabeversion 4.2 meines Projekts?
Versionskontrollsysteme:
- Unterstützen Entwickler bei der Verwaltung ihrer Projekte
Versionskontrollsysteme
- Erste Generation: lokal
- ~1972: SCCS (Source Code Control System)
- ~1982: RCS (Revision Control System) für kleinere Projekte
- Zweite Generation: Zentraler Server
- CVS (Concurrent Versions System)
- Mehrere Entwickler/Autoren
- Subversion (SVN)
- Web-integrierter Nachfolger von CVS
- Bezüge zwischen Dateien
- Dritte Generation: verteilt, offline-fähig
- Arch (TLA), darcs, monotone; svk; ...
- git, mercurial (hg), bzr
Umfang der Versionskontrolle
- Was behält man unter Versionskontrolle?
- Alles von Menschen Erdachte
- Quell-Dateien
- Style-Sheets
- Konfigurationsdokumente (Makefiles, XML-Catalog-Files)
- Dokumentation
- Informationen über ein Projekt
- Testdaten/-Skripte
- Was nicht?
- Alles automatisch generierte
- Durch Transformation erzeugte Dokumente
- Kompilierte Module und Programme
- Alles, was automatisch wiederhergestellt werden kann
Parallele Entwicklung
- Größere Projekte
- Entwicklung komplexer Softwaresysteme
- Entwicklung von Websites
- Einbeziehung mehrerer Entwickler
- Paralleles Arbeiten, z.B.:
- Entwickler A schreibt neue XML-Dokumente
- Entwickler B arbeitet an XSLT-Style-Sheets
- Jeder Entwickler benötigt konsistente Kopie des Projekts (Arbeitskopie)
- Unabhängige Weiterentwicklung
- Hinzufügen neuer Module
- Synchronisieren
- Zurverfügungstellen der eigenen Änderungen
- Aktualisieren der eigenen Arbeitskopie
Versionskontrolle der dritten Generation
- Mehrere Repositories arbeiten zusammen
- Lokale commits („commit before merge“)
- Push-/Pull-Operationen zwischen Repositories
- DAG-Struktur wird leichtgewichtiger
- merge, rebase
Versionskontrolle mit git
- Arbeitsstil:
- branch anlegen
- repeat until done:
- merge branch to master
- Währenddessen: push, pull
AWE: git-Repositories
- Vorbereitung:
- Windows: ________
- Mac: macports… port install git-core
- Linux: apt-get…
- Zugang:
- ssh-keygen
- Key(s) als attachment an net@tzi.de (mit Gruppennummer), sobald Gruppennnummer klar
git init
...
git remote add origin awe12@robinson.informatik.uni-bremen.de:awe4711
git fetch
git push origin master
Mac OS X: UNIX
- Normale UNIX-Umgebung
- X11 allerdings eher unüblich
- Programme starten: Launcher
- Von der Kommandozeile:
open ...
- Einstellungen:
- System Preferences
- z.B. Keyboard&Mouse → Keyboard → Modifier Keys
- Editieren:
- Selbst installieren: Emacs, Textmate (Demoversion), Eclipse/Aptana, Netbeans
- Browser:
- Git-Browser: gitx
Ruby auf den Macs
- Drei Ruby-Versionen
- 1.8.7:
/usr/bin/ruby
- 1.8.7:
/opt/local/bin/ruby mit einigen gems
- kein Ruby 1.9 in Reichweite…
- Rails ist auf Macs im System enthalten (zu
/usr/bin/ruby)
- Up to date: rvm installieren, mit 1.9.3-p125 und rails3
- (rvm wie gewohnt installieren)
rvm get headrvm install ruby-1.9.3-p125-falcon
- Installation eigener Gems:
Rails
rails new meinprojekt
cd meinprojekt
rails generate scaffold ...
rake db:migrate
rails server &
open http://localhost:3000
fg
Heroku
- Beliebter Deployment-Server
- Kostenlose Accounts
- Kennt Ihr schon aus railstutorial
- Real Artists Ship
Wiki (1)
- Jeder macht sich einen Account der Form:
VornameNachname
- Bitte cabo@tzi.org Bescheid sagen
- Bitte eine kurze Selbstbeschreibung wie in
CarstenBormann anlegen
- Jede Gruppe macht sich eine Seite der Form
Gruppe/07
- Mitglieder verlinken
- Thema kurz beschreiben/verlinken, sobald bekannt
- Tip Jar
- Jeden Tag gibt es ein Protokoll der Form
Tag/01
Wiki (2)
- Wissensbasis
- Interessante Links
- Rezepte (z.B. für OpenID)
- Koordination von
- Abschlußpräsentationen
- Fachgesprächen
- Mittagessen am Sonnabend :-)
Tagesziel für Montag
- Flüssig mit den Tools arbeiten können
- Paarprogrammierung, TDD weiter einüben
- Miniprojekt: kleine Rails-Anwendung schreiben:
- Teilnehmerverwaltung AWE11
- Nicht fokussieren auf:
- Aussehen
- Benutzerverwaltung, Authentisierung, Autorisierung, ...
- “Benutzer” einfach in die Session schreiben!
- Gimmicks (AJAX, ...)
Das Miniprojekt (1)
- Wie müßte eine AWE-Teilnehmerverwaltung aussehen?
- Papierlose, E-Mail-arme Durchführung
- Startphase unterstützen
- Gruppenbildung
- Repos für Uebungsaufgaben erfassen
- Veranstalter: Projekte verwalten
- Start Arbeitsphase unterstützen
- Updates Gruppenbildung
- Projektzuweisung
- Arbeitsphase unterstützen
- Kontakt zu Kunden pflegen, Stand, Tickets, Tasks, ...
Das Miniprojekt (2)
Was üben wir heute?
- Superkurze Iterationen
- Paarprogrammierung
- Über die Hürde hinwegkommen
- Arbeiten mit den Tools
- nicht: Einhalten von Kundenanforderungen
- Heute ist mal Eure Phantasie gefragt!
Legitimate Peripheral Participation
- Lehrling/Meister
- Häufiger mal die Runde drehen
- Nicht stören
- offen empfangen
- Stand erklären, zeigen, diskutieren
- Tip jar nicht vergessen…
- In der Wiki-Seite der Gruppe, die geholfen/Ideen beigetragen hat
AWE: Essentials
- Paarprogrammierung
- Testgetriebene Entwicklung (TDD/BDD)
- Leben in git
- Wiki
- The customer is king
- release early, release often
- Deploy in Heroku
- Deploy auf Macs