Git / Gitolite

Ubuntu Git-Server / Gitolite einrichten

Git ist ein sehr gutes und vielseitiges Versionierungssystem. Mit Git lassen sich beliebige Projektgrößen sauber und einfach versionieren. Vor allem Firmen, die sich für eigene Softwareentwicklung entschieden haben, sollten ihre Software einer Versionskontrolle unterziehen. Einige lassen Ihre Git-Repositories bei externen Anbietern hosten. Die anderen Wollen ihre Sourcen den Hostern nicht anvertrauen und setzen eigene Server auf. Es gibt sehr unterschiedliche Möglichkeiten eigenen Git-Server aufzusetzen. Eine einfache ist die Verwendung eines Ubuntu-Servers in Verbindung mit Gitolite.

Ubuntu-Server (http://www.ubuntu.com/server)
Gitolite (http://gitolite.com)

Konfiguration des Ubuntu Servers

Git-Core installieren

sudo apt-get install git-core
sudo apt-get install git

Gitolite installieren

sudo apt-get install gitolite

Git/Gitolite Benutzer hinzufügen (Password wird weg gelassen)

sudo adduser --system --group --shell /bin/bash --disabled-password git

Wird ein Password benötigt?

sudo passwd git

Konfiguration von Clients auf Linux oder Widows

Shell-Befehl zum erzeugen des ssh-Keys.

ssh-keygen -t rsa

Linux

Direkt die Shell öffnen und den Befehl eingeben. In dem Benutzer-Verzeichnis sollte ein Ordner .ssh mit zwei Dateien erzeugt werden.

Private Schlüssel: id_rsa
Öffentlicher Schlüssel: id_rsa.pub

Falls Git nicht auf der Client-Maschine vorinstalliert wurde, muss dieser nachinstalliert werden.

Windows

Die Client-Konfiguration unter Windows erfolgt zuerst mit der Installation von Git. Bitte herunterladen und installieren (https://git-scm.com/) Nach der Installation, die Git-Bash öffnen und den oberen Befehl eingeben. Nach der Ausführung sollte in dem Benutzer-Verzeichnis ein Ordner .ssh mit zwei Dateien erzeugt werden.

Private Schlüssel: id_rsa
Öffentlicher Schlüssel: id_rsa.pub

Den Public-Key(.pub) auf den Git-Server kopieren.

scp ~/.ssh/id_rsa.pub username@git_server_IP_address:/tmp/git-admin.pub

Den Git-Server abschließend konfigurieren

In der Konsole als Git-User einloggen

sudo su git

Konfiguration von Gitolite anstoßen

gl-setup /home/git/.ssh/git-admin.pub

Gratulation, der eigene Git-Server ist jetzt einsatzbereit!

Git-Benutzer mit Gitolite verwalten

Voraussetzung ist die Installation von Git auf der Client-Maschine.

Das Gitolite, Repository klonen.

git clone git@git_server_IP_address:gitolite-admin

Nach dem Klonen wird ein Verzeichnis gitolite-admin erzeigt in dem sich zwei weitere Unterverzeichnisse befinden.

gitolite-admin
       | - conf
       | - keydir

In das Verzeichnis keydir werden öffentliche ssh-keys der nötigen Git-Benutzer rein kopiert.

cp /path/to/benutzer/public/key.pub ~/gitolite-admin/keydir/benutzer.pub

Anschließend wird die die gitolite.conf Datei in dem Verzeichnis conf editiert.

Der Datei-Aufbau sollte sich wie folgt zusammensetzen:

repo gitolite-admin
         RW+        =     git-admin

repo meinprojekt
         RW+       =      benutzer

Drei mögliche Rechte können an Benutzer vergeben werden:

R: Nur lesen
RW: Lesen und Ändern, die Git-Referenzen können allerdings nicht modifiziert werden.
RW+: Vollzugriff(löschen und modifizieren der Git-Referenzen möglich)

Mit den letzen Befehlen teilen Sie Gitolite die Änderungen mit

git add .
git commit -a -m “Erstelle meinprojekt Repository ”

Das neue Reppository wurde erzeugt und kann benutzt werden! Beleibt noch die Option dieses Repository auf die lokale Maschine zu klonnen:

git clone git@git_server_IP_address:meinprojekt

Abschluß

Das Gitolite, erlaubt es den Git-Server leicht zu verwalten. Benutzer, Repositories und deren Rechte können ebenfalls unkompliziert gesetzt oder entfernt werden. Dabei bleibt das installierte Betriebssystem geschützt. Der Administrator braucht sich nicht um alle Benutzer des Betriebssystem zu kümmern. Das Tool-Gitolite erlaubt es sich nur auf die Versionskontrolle zu konzentrieren ohne zusätzlichen Betriebsystemabhängigen Aufwand.


TDD

Was ist TDD?

TDD – steht für Test Driven Development (Test-Betriebene Entwicklung). Viele erfahrene Programmierer und Fachleute verwenden oft diesen Begriff. Sie erzählen von unglaublich stabilen und qualitativ hochwertigen Applikationen, die genau nach dieser Methode entwickelt wurden. Vor allem für unerfahrene Entwickler klingt das Ganze nach einer sehr hohen und mysteriösen Kunst, die nicht jeder beherrscht und beherrschen kann. Dabei ist es ein einfaches Konzept, den jeder in seine alltägliche Arbeit einbringen kann und auf jeden Fall einbringen sollte.

Was ist eigentlich TDD?

Nun, das lässt sich leicht mit zwei Sätzen schildern:

  1. Zuerst wird der Test geschrieben, danach die eigentliche Implementierung!
  2. Für jede Methode und Funktion der Klasse gibt es mindestens einen Test.

TDD Rhythmus

Die testbetriebene Entwicklung weist einen sich ständig wiederholenden Rhythmus auf:

  1. Das Schreiben eines Tests der durchfällt (FAIL)
  2. Implementierung der eigentlichen Klasse, Methode oder Funktion, bis der Test besteht (SUCCESS)
  3. Optimierung des Codes, durch Refaktoring: (REFACTOR)
    • bessere Namen
    • Entfernung der Duplikate
    • Verbesserung der Lesbarkeit

Grafische Darstellung:

TDD

Einzelschritte der testbetriebenen Entwicklung

FAIL

Aller Anfang ist schwer! Viele Entwickler wissen nicht womitsie starten sollten.Womit soll der Test beginnen? Welcher Test soll als erstes geschrieben werden?

Die nachfolgenden Punkte sollen eine Hilfestellung leisten:

  • Fangen sie ganz einfach an (Nullprüfung, Parameterprüfung, usw.)
  • Gehen sie vom Leichtem zum Schwierigem übergehen
  • Erst das Wichtigste, dann die Details
  • Hören sie auf innere Stimme: Erfahrung

SUCCESS

  • Schreiben sie das Einfachste, es soll nur funktionieren
  • Gehen sie mit der Implementierung nicht zu weit, der Test soll nur Grün werden
  • Test bestanden, super, sie brauchen nichts mehr (denken sie nicht an die potenziellen Möglichkeiten der Klasse, Methode oder Funktion)
  • Konzentrieren sie sich nur auf die eine konkrete Implementierung, vergessen sie aber nicht das Gesamtbild

REFACTOR

  • Code läuft, super, ist dieser aber auch lesbar?
  • Besteht Verbesserungs- oder Optimierungspotenzial
  • Befolgt die Implementierung alle OO-Regeln
  • Test erfolgreich? Sein sie so frei diesen Code zu perfektionieren
    • entfernen sie Duplikate
    • vergeben sie bessere Namen an Variablen, Funktionen oder Methoden
    • überprüfen und ändern sie die Sichtbarkeit der Variablen, Funktionen und Methoden
    • Sie dürfen Teile des Codes verschieben, entkernen und säubern
    • Starten sie den Test erneut nach jeder Änderung

Warum eigentlich nach TDD -Methode entwickeln?

  • Der gesamte Code ist getestet und überprüft (Qualitätsmerkmal)
  • Der Code ist sauber, dieser ist nur für den Durchlauf der Test geschrieben nichts Überflüssiges (schlank)
  • Der Code konzentriert sich auf eine Problem (Konkret)
  • Nach der Reorganisation ist der Code immer noch sauber und kann immer getestet werden (keine Furcht vor Veränderungen)
  • Sie können immer leicht aus dem Test in den Code springen (Problem einkreisen)

Schritt für Schritt „test-first“

  1. Denken sie drüber nach was die Klasse tun soll
  2. Schreiben sie zu der Klasse einen Test
  3. Legen sie die Klasse leer an
  4. Führen sie den ersten Test aus (FAIL)
  5. Erweitern sie den Test mit nötigen Informationen
  6. Es ist Zeit den Klassencode zu schreiben
  7. Klasse fertig?! Führen sie den Test aus, dieser sollte von Rot auf Grün umschalten (SUCCESS)
  8. Säubern Sie ihren Code, verbessern und optimieren sie ihre Klasse. Machen sie die Klasse informativer, geben sie allen Variablen, Methoden, Funktionen sprechende Namen.
  9. Starten sie den Test neu, bestanden? Sie haben Ihre Aufgabe gemeistert! Glückwunsch!

Stellen sie die Qualität Ihrer Software sicher, in dem sie immer nach der TDD-Methode entwickeln. 


Clean Code / Sauberer Code

Programmieren ist nicht gleich Programmieren!

Viele Entwickler programmieren mit dem Ziel, das Programm fertig zu schreiben und zum Laufen zu bekommen! Das ist der schlechteste Ansatz, den man wählen kann. Damit wird dem Kunden und dem Entwickler jegliche Möglichkeit genommen, das Programm zukunftssicher zu gestalten.

Ein guter Entwickler möchte sein Programm nicht nur runter programmieren, er möchte mit seinem Sourcecode eine Geschichte erzählen, so wie ein Geschichtsschreiber. Ab heute sind Sie ein Geschichtsschreiber, aber bitte kein Märchenerzähler.

Sprechende Namen

Damit sind wir am ersten Punkt angelangt! Ein guter Programmierer wählt immer sprechende Namen. Die Namen von Variablen, Methoden oder Klassen müssen das Vorhaben des Programmierers wiedergeben. Außerdem muss der gewählte Name drei Fragen beantworten können:

  • Warum existiert diese Variable, Methode, Klasse?
  • Was macht sie?
  • Wie wird sie benutzt?

Die gewählten Namen müssen leicht lesbar und aussprechbar sein, bitte keine unverständlichen Abkürzungen und Ausdrücke. Die Objektnamen und Klassennamen sind immer Substantive: „Customer, Page, Book, …“. Die Namen der Methoden sind immer Verben oder Verbalphasen: „addCustomer, removePage, …“.

Wichtig: Nehmen Sie sich genug Zeit für die Wahl, eines sprechenden Namens. Es lohnt sich!

Funktionen und Methoden

Eine gute Geschichte lässt sich leicht in Kapitel, Abschnitte, Absätze und Verse aufteilen. Das Gleiche gilt für den Sourcecode. Dieser lässt sich leicht in übersichtliche Methoden und Funktionen aufteilen.

Eine Methode oder Funktion sollte:

  • Kompakt sein (passt auf den Bildschirm)
  • Nur eine Operation ausführen (keine Seiteneffekte, nur ein Arbeitsschritt)
  • Lesbarkeit (von oben nach unten)
  • So wenig wie möglich Übergabeparameter / Argumente enthalten (keine Parameterübergaben ist am besten)
  • Niemals ein Eingangsparameter neu gestalten (keine direkte Modifikation)
  • Keine Flags benutzen (Flags sind hässlich)
  • Keine Seiteneffekte enthalten (Eine Methode macht nur das, was ihr Name verspricht)
  • Kein null zurück geben (sie bekommen früher oder später eine NullPointerException)
  • Eine Anfrage oder eine Operation sein, nicht beides gleichzeitig

Ausnahmen

In professionellen Fachzeitschriften finden Sie immer Fußnoten mit Zusatzinformationen zu dem Hauptlesestoff. Die Fußnoten können Sie überspringen, diese liefern Ihnen dennoch wichtige Informationen, wenn Sie ins Detail gehen möchten. Ähnlich verhält es sich mit Ausnahmen (Exception), sie sollten nicht oft oder gar nicht auftreten. Kommt es zu einer Ausnahme, sollte diese sehr informativ und tiefgründig sein.

Umgang mit Ausnahmen:

  • Isolieren Sie try / catch Bloks in Methoden
  • Verwenden Sie immer Laufzeitausnahmen (RuntimeExceptions)
  • Übergeben Sie immer den Kontext bei einer Ausnahme (niemals null)
  • Definieren Sie eigene Ausnahmen (Benutzen Sie eine Ummantelung [Wrapper]. Befreien Sie sich von fremden Abhängigkeiten / Ausnahmen)

Dokumentation

Wie sieht es mit Dokumentation aus? Eine Gegenfrage: Schreiben Sie zu einer Geschichte irgendeine Dokumentation? Der Sourcecode sollte selbsterklärend sein. Lassen sie die Dokumentation weg.

Sprachkonstrukte / Formatierung

Unterschiedliche Geschichtsschreiber schreiben unterschiedlich. Dennoch gibt es ein paar Leitlinien, an die man sich halten sollte.

  • Einen switch isolieren Sie immer in eine Funktion und liefern Sie das nötige Ergebnis
  • Versuchen Sie die Klassen klein zu halten, nicht mehr als 500 Zeilen
  • Maximal 100 bin 120 Symbole in einer Zeile
  • Funktionen, die voneinander abhängig sind, sollten sich in der Nähe befinden
  • Programmieren Sie immer gegen eine Schnittstelle, nicht gegen eine konkrete Implementierung
  • Bitte programmieren Sie keine Ketten (list.get(index).get(item).get(object).name();)

TDD – Test Driven Development

Eine echte Geschichte, die der Wahrheit entspricht, wird durch archäologische Ausgrabungen geprüft und bestätigt. Sourcecode sollte immer Tests unterzogen werden. Der beste Ansatz dafür ist Test-Gestützte-Entwicklung. Wer Test-Betrieben programmiert, produziert mit Sicherheit einen besseren Sourcecode, als derjenige der sich auf die Implementierung stürzt.

Axiome des TTD:

  • Schreiben Sie zuerst Test, dann den eigentlichen Code
  • Schreiben sie den Test bis zu Verweigerung (Kompilierung nicht mehr möglich)
  • Schreiben Sie nur so viel Code wie nur nötig, um den Test zu bestehen

Tests und das eigentliche Produkt werden zeitgleich geschrieben. Halten Sie ihre Tests sauber!

F.I.R.S.T.

Die Umsetzung der Tests können Sie nach der F.I.R.S.T. Spezifikation prüfen

  • F – Fast / Schnell (Die Tests laufen schnell ab)
  • I – Independent / Unabhängig (Keine Abhängigkeiten unter den Tests)
  • R – Repeatable / Wiederholbar (Unter beliebigen Umständen)
  • S – Self-Validating / Offensichtlich (Einfach: Bestanden JA / NEIN)
  • T – Timely / Rechtzeitig (Schreiben der Tests vor der eigentlichen Implementierung)

Neue Bibliotheken und Frameworks

Ein Schreiber entwickelt sich immer weiter, sein Text wird vollständiger und genauer. Ein Entwickler erweitert seine Möglichkeiten durch die Aneignung neuer Bibliotheken und Frameworks. Die beste Möglichkeit dies zu tun sind Training Tests.

  • Training Tests sind kostenlos
  • Sie sind nützlich und effektiv

Prüfung des Sourcecodes

Nach dem der Geschichtstext fertiggestellt wurde, muss dieser Korrektur gelesen werden. Um mögliche orthografische und inhaltliche Fehler zu beseitigen. Der Sourcecode muss ebenfalls geprüft werden.
Die wichtigste Aufgabe ist es sicher zu stellen, dass die Architektur so einfach wie möglich definiert wurde.
Definition der Einfachheit (Wichtigkeit von Oben nach Unten):

  • Sicherstellung der Testdurchläufe
  • Enthält keine Duplikate
  • Spiegelt das Vorhaben des Programmierers wieder
  • Benutzt minimale Anzahl an Klassen und Methoden

Schreiben Sie Ihre eigene Geschichte und behalten Sie dabei folgendes immer im Hinterkopf:

Den Sourcecode zum Laufen zu bringen ist nicht professionell! Testen Sie den Sourcecode und halten Sie ihn immer sauber!


Snake

Ein kleines Spiel „Snake“ zum Zeitvertreib umgesetzt in Java. Das besondere an dem Spiel ist: Unsere Schlange ist freundlich und isst Früchte anstatt Mäuse. Jagen Sie den Früchten hinterher und lassen Sie Ihr Haustier groß und lang werden.

VORSCHAU

snake

DOWNLOAD

Spiel: snake.zip
Projekt: SnakeProjekt.zip

BESCHREIBUNG

Voraussetzungen
Java(JRE) Version 1.7 oder höher.

Einrichten
Nach dem Herunterladen, Archiv entpacken und durch den Befehl java -jar snake.jar  das Spiel starten.

Steuerung
Durch Pfeiltasten: rechts, links, oben und unten wird die Schlange gesteuert. Mit der P-Taste kann das Spiel pausiert werden.
Über Menü->New game können Sie das Spiel neu starten.
Viel Spaß beim spielen! 😉


Stundenbuchungssoftware

Sie sind Freiberufler oder Freelancer? Buchen Sie ihre Stunden immer noch in einer Excel-Liste? Erstellen Sie Rechnungen in einer Word-Datei?

Hier finden Sie eine kostenlose und einfach zu bedienende Softwarelösung für Ihre Stundenbuchung und Rechnungserstellung.

VORSCHAU

StundenbuchungImage

DOWNLOAD

Version 1.4
Windows: Stundenbuchung_win.zip
Linux: Stundenbuchung_linux.zip
Multiplattform: Stundenbuchung_1_4.zip

Was ist neu: In der Version 1.4 können Sie sich unter Einstellungen zwischen Buchung der Stunden oder Stückzahlen entscheiden.

Version 1.3
Multiplattform: Stundenbuchung_1_3.zip

BESCHREIBUNG

Voraussetzungen
Java(JRE) Version 1.7 oder höher.

Einrichten
Nach dem Herunterladen, Archiv entpacken. In dem Ordner „data“ die Datei „firmenlogo.png“ durch eigenes Logo ersetzen.
Windows:  Applikation in der Eingabeaufforderung durch den Befehl java -jar Stundenbuchung.jar starten.
Linux:         Applikation in einem Terminal durch den Befehl java -jar Stundenbuchung.jar starten.

Einstellungen und Bedienung
Programm starten. Im Menü Programm->Einstellungen wählen und eigene Daten eintragen. Rechnungen werden über den Menü-Eintrag Rechnungen erstellt.