Eine Chance für den Idioten

Ja richtig, es geht um Quellcodeverwaltung. Lange habe ich mich gluckend über meine Subversion-Repositories geworfen. Quellcodeverwaltung mit Git (dt: Idiot) habe ich eher den Bastlern zugeordnet. Nachdem ich aber komplett umgestiegen bin möchte ich hier eine Lanze brechen. Drei Punkte und Mythen mit denen man aufräumen muss, damit man auf dem Weg zum Git-Freund ist:

#1 Git kennt keinen Server! Lange lebe mein Git-Server!

Es gibt keinen Git-Server. D.h. Git ist nur was für Filesharer, oder wie? Eigentlich stimmt das nicht. Man kann sich ein zentrales Repository anlegen und mit seinem Team darin arbeiten. Das ganze nennt sich Bare-Repository. Man braucht nichts weiter als einen Raspberry mit Linux oder irgendwas anderes mit einem Pinguin um zu starten.

sudo apt-get install git
mkdir MyRepo.git
cd MyRepo.git
git init --bare

Danach noch TortoiseGit auf die Windows-Maschine installieren. Die Kommunikation läuft im Hintergrund über SSH/Putty. Fertig!

#2 Meine Commits gehören mir!

Wenn ihr einen Git-“Profi” fragt, was die Vorteile gegenüber Subversion sind, würde wahrscheinlich sowas kommen: “Git braucht keinen Server”, “Git eignet sich besser für extrem verteilte Teams” oder “In Git sind Konflikte kein Problem, sondern gewollt”. Alles ziemlich abstrakt und für mich auch nicht wirklich griffig.

Wenn ihr mich als Git-Anfänger fragen würdet, würde ich sagen “Lokale Commits!”. Es ist einfach richtig geil jederzeit committen zu dürfen ohne dass ein Server da sein muss oder man Gefahr läuft in Konflikte mit den Kollegen zu laufen. Sobald ihr einen Stand habt, der in das Haupt-Repository soll, wird gepusht.

Übrigens auch nett ist, dass man natürlich auch gegen jedes andere Repository pushen kann. Wenn ihr also gerne ein Backup macht, bevor ihr eure Änderungen in die weite Welt entlasst, dann pusht ihr vorher gegen euer Backup-Repository.

#3 Den Segen von Microsoft

Mit Linux hat der Beitrag begonnen, mit M$ endet er. Auch die Redmonder haben das Potential von Git entdeckt und im TFS zum “Bewohner erster Klasse gemacht”. Ich wette der Torwalds hatte ne Woche dauergrinsen als er davon gehört hat.

Es muss nicht immer Scrum sein

Wer sich mit agilen Vorgehensmodellen in der Softwareentwicklung beschäftigt, kommt an Scrum nicht mehr vorbei. Dabei ist gerade dieses Modell wohl eines der Komplexesten seiner Gattung. Wer auf der Suche nach einem Einstieg in die die agile Welt ist verliert sich hier schnell in Regeln, Rollen und Konventionen. Aber muss es tatsächlich immer Scrum sein? Hier sind fünf Tipps für die täglichen “agilen Kick”.

#1 Informelle Arbeitsumgebung

6129928164_99a3262ca8_z Was tue ich gerade? Was muss ich als nächstes tun? Was habe ich bereits erledigt? Diese drei simplen Fragen gilt es permanent im Blick zu halten.

Zu sehen womit ich gerade beschäftigt bin fokussiert mich auf meine Aufgabe und vermeidet Ablenkungen. Den Blick auf die noch zu erledigenden Aufgaben verhindert ein Gefühl der Überforderung. Das abhaken von Aufgaben motiviert mich und signalisiert mir, dass es voran geht.

Ein physisches Kanban-Board  ist hier ein tolles Werkzeug. Nimm dir Zeit Aufgaben zu dokumentieren und zu strukturieren. Softwarewerkzeuge wir JIRA oder Microsoft TFS können zur Hilfe genommen werden. Die Flexibilität von Stift und Papier ist aber unerreicht.

#2 Das Daily

Scrum sieht vor ein tägliches, viertelstündiges Meeting zum besseren Austausch zu halten. Dies ist generell eine gute Idee und tut jedem Team (egal ob nun agil oder nicht) gut! Nimm dir also eine Tasse Kaffee und plaudere morgens ein bisschen mit den Teamkollegen. Aber haltet euch unbedingt an die vorgegeben 15 Minuten. Setzt euch nicht hin und achtet darauf tiefergehende Diskussionen in eigene Termine auszulagern.

#3 Schätzpoker

Es gibt wohl kaum etwas Unbeliebteres ist als Aufwände zu schätzen. Warum die Sache deshalb nicht etwas auflockern? Anstatt Aufwände auszusprechen und direkt rechtfertige zu müssen, schreiben alle Teilnehmer ihre Einschätzung verdeckt auf ein Blatt Papier. Sinnvoll ist, dass man sich auf eine Skala einigt. Alle decken ihre Aufwände gleichzeitig auf und diskutieren. Liegen die Aufwände im gleichen Rahmen ist alles in Ordnung und man sollte schnell fertig sein. Kommt man allerdings auf völlig unterschiedliche Einschätzungen könnte etwas mit der Formulierung der Problemstellung nicht stimmen.

#4 The Walking Sceleton

Wenn du eine neue Funktion einbaust versuche nicht die eierlegende Wollmilchsau aus dem Stand zu erstellen. Funktionierende Software ist wichtig und deine persönliche Bestätigung. Baue der einen Pfad der funktioniert, aber noch steinig ist. Iterativ verbesserst du deine Software zum gewünschten Ergebnis.

#5 Sprints

Auch wenn deine Auftraggeber nicht viel Wert darauf legen, organisiere dich in Sprints. Setze dir Milestones und bespreche diese mit dem Kunden/deinem Team. Ein Zeitraum von 14 Tagen ist überschaubar und handlich. Monatelang im Elfenbeinturm zu programmieren kann zu einem bösen Erwachen führen.

Literaturempfehlung

Es wird viel zum Thema geschrieben. Wer einen komprimierten Einstieg sucht ist mit diesen Werken gut aufgehoben.

Teacha: TypeScript works!

teacha_48Bisher habe ich nur wenige Webanwendungen oder Apps  in TypeScript gefunden. Microsoft hat vor kurzem offiziell die Version 1.0 freigegeben. Ein Beispiel, dass TypeScript funktioniert ist die App Teacha. Teacha ist ein digitales Notenbuch für das Microsoft Surface bzw. Windows 8.1. Ein weiteres Beispiel ist übrigens der XBOX Music Store, der bereits 2013 auf der //BUILD vorgestellt wurde.

SAP: Testversion von Netweaver wiederbeleben

Nach einigen Wochen Pause wollte ich kürzlich meinen Netweaver-Spielplatz wieder betreten. Wie schon zu erwarten, war die Testlizenz abgelaufen. Leidensgenossen wissen, wie nervig eine Neuinstallation ist (da sollte man schon acht Stunden Rechnerzeit einrechnen). Also neue Lizenz beantragt und eingespielt. Aber wie war noch das Passwort für SAP*?

Continue reading