Nachdem ich viele Stunden meines Lebens bereits mit dem Vorgänger verbracht habe, war ich neugierig auf das, was hier gemacht wurde. Mit Interesse habe ich im Vorfeld Berichte verfolgt und wusste schon, dass einiges anders werden würde. Aber dazu später mehr.

Zuerst einmal wird installiert, was gefühlt relativ lange gedauert hat. Anschließend gings für mich an die Erstellung eines battle.net-Accounts, ohne den man nicht spielen kann. Einer der Nachteile ist, dass man zum Spielen eine Internetverbindung benötigt – nicht nur zum Login, sondern dauerhaft. Mir ist es einmal passiert, dass ich aus dem Spiel flog, weil die Verbindung zu den Battle.Net-Servern unterbrochen war. Das ist unschön, muss man die Kunden bei einem nicht billigen Spiel noch derart gängeln? Login-Probleme, wie sie heute in den frühen Morgenstunden oder am Abend aufgetreten sein sollen, hatte ich nicht.

Nach der Anmeldung gings an die Charakter-Erstellung. 5 Klassen stehen zur Auswahl und man darf sogar das Geschlecht wählen. Mich hat am meisten die Mönchen gereizt und somit mein erster Char. Altbekannt sind der Barbar und die Zauberin, der Dämonenjäger erinnert mich an die Assassine aus Teil 2 und der Hexendoktor hat ein bisschen was vom Necro.

Ich starte erstaunlicherweise quasi nackt mit nur einem alten Schlagring ausgerüstet. Nach wenigen Metern und den ersten Gegner bin ich in Neu-Tristram angelangt und kümmere mich um die ersten Quests.

Die Story ist gut erzählt, die Gegenden sind wieder zufällig erstellt. Der Eindruck ist gut, immer wieder gibts versteckte Schätze oder auftauchende Gegner. Für große eliminierte Gegnergruppen bekommt man Bonus XP, das gefällt mir gut und gibt Anreize keine Kampfpausen zu machen.

Ich habe einen primären und einen sekundären Angriff. Der erste lädt Seelenenergie auf, der zweite verbraucht sie wieder. Da ich die Energie nur im Kampf aufladen kann, habe ich natürlich auch Interesse daran, dass um mich herum immer Action ist.

Das Skillsystem ist komplett anders. Ich lerne die Skills in festgelegter Reihenfolge beim Level-Aufstieg. Es gibt eine Reihe von Grundfertigkeiten, welche durch Runen aufgemotzt werden. Meinem Donnerschlag verpasse ich eine Teleportfunktion und bin dadurch sofort am Feind, meine Tritte bekomme mit einer Prise Flammen das gewisse Extra.

Neben primärem und sekundären Angriff kann ich vier unterstützende Fähigkeiten auswählen, auch hier bekommt man nach und nach alles, kann aber immer nur eine Fähigkeit einer Art auswählen.
Die Lösung ist gut und verhindert, dass man sich – wie es sicherlich vielen in Diablo 2 passiert ist – verskillt. Wichtiger ist nun, wie man die Fähigkeiten kombiniert und eben auch die eingesetzte Ausrüstung.

Auf Normal kommt man gut gegen die Gegnermassen an. Sollte es doch mal brenzlig werden hat man nun eine Taste, mit welcher man sich einen Heiltrank einwerfen kann. Aber Vorsicht, diese haben nun einen Cooldown!

Die Abwechslung im Gegnerdesign hält sich noch in Grenzen, aber ich habe mit Level 9 noch nicht so viel von der Welt gesehen. Dabei war ich schon stark umtriebig, die Story treibt mich umher. Zwischendurch habe ich immer wieder schmunzeln müssen und mich gefragt, ob dieses oder jenes bewusst eine Anspielung auf alte Zeiten war. Apropo alte Zeiten: man trifft wieder auf alte Bekannte

Die Grafik in Diablo 3 wirkt anständig. Es gibt keine großen Überraschungen, es hätte durchaus düsterer ausfallen können. Meinem Kentnissstand nach wird hier noch mit Direct X 9 gewerkelt, weswegen auch Spieler mit älteren Rechnern zum Zug kommen können.
Nervig ist leider, dass der Lüfter meiner Grafikkarte relativ laut dreht und ich nicht sehe, weshalb das so ist. Vielleicht legt Blizzard durch einen Patch nach, vielleicht behebt ein neuer Nvidia-Treiber das Problem. Wie auch immer, momentan nervts, da dadurch der Geräuschpegel im Raum relativ konstant auf einem nicht mehr einfach überhörbaren Level sind.

Nach meinen 2 Stunden Spielzeit bin ich insgesamt recht zufrieden. Die deutsche Übersetzung ist gut, ich habe bisher keinen Grund auf Englisch umzustellen. Man kommt sogar in den Genuss von Blutspritzern und auseinanderfallenden Gegnern. Es gibt viel zu entdecken und ich bin gespannt, wie die Story sich weiterentwickelt!

CI-Tool meiner Wahl ist Jenkins. Ich bevorzuge Jenkins gegenüber Hudson, weil Jenkins hinter sich eine aktive Community hat und mir Hudson relativ tot aussieht. Nach der Übernahme Suns durch Oracle wurde das Hudson-Projekt geforkt und als Jenkins durch die Community weiterentwickelt. Hudson wurde irgendwann zum Sterben in die Hände der Eclipse Foundation gelegt – ungefähr so, wie es Oracle bereits mit OpenOffice getan hat.
Die aktive Jenkins Community sorgt für die Weiterentwicklung und es gibt regelmäßig, alle 2 Wochen, Releases.

Ich will hier zeigen, wie wir uns mit wenig Aufwand eine eigene Jenkins-Instanz mit unsere Entwicklung unterstützenden Tools aufbauen können.

Installation

Das System habe ich auf einem Ubuntu Server aufgebaut. Die Installation erfolgte mittels den auf der Jenkins-Seite beschriebenen Schritten.

Nach der Installation wurde Jenkins automatisch gestartet und war fortan unter localhost:8080 zu erreichen.

Plugins

Jenkins lässt sich durch eine große Menge an Plugins erweitern. Aber viele davon brauchen wir nicht, der Zugriff auf die Versionverwaltung unserer Wahl und das Violations-Plugin reichen für den Anfang vollkommen aus.

Violations

Ich wähle das Violations-Plugin für die spätere Verwendung von pylint und pep8.
Da uns die über die Ubuntu-Repos installierte Version das Violations-Plugin nicht anzeigt, installieren ich es von Hand. Dazu laden wir es über diesen Link herunter und wählen in der Jenkins Verwaltung bei Plugins die Erweiterten Einstellungen. Dort habe ich dann die Möglichkeit eines manuellen Uploads.

Jobs einrichten

Nun können wir mit der Einrichtung unseres Projekts in Jenkins beginnen. Wir rufen natürlich Jenkins auf und clicken links auf Neuen Job anlegen. Wir wählen einen aussagekräfitgen Namen und wählen “Free Style”-Softwareprojekt bauen. Der Jobname sollte keine Underscores enthalten, da die Jenkins Shell damit Probleme haben kann.

Jenkins: Job erstellen

Auf der folgenden Seite haben wir dann eine Menge an Einstellungsmöglichkeiten. Unter den erweiterten Projekteinstellungen kann auch ein neuer Anzeigename gewählt werden – diesmal auch mit Leerzeichen.

Versionskontrolle

Hier können wir auch den Zugriff auf unser Versionskontrollsystem einstellen. Ich nutze hier ein git-Repository. Damit nicht alle Dateien im Jenkins-Workspace rumliegen, packen wir das Repository in einen Unterordner. Dies gehört bei git zu den erweiterten Einstellungen und ist als Local subdirectory for repo (optional) zu finden. Wir tragen dort den Wert repo ein.

Das automatische Durchführen unserer Build-Schritte ist auch möglich. Entweder wir geben von vornherein Zeiten fest, zu welchen gebaut werden soll, oder aber wir geben an, wann unsere zuvor eingetragenes Repository auf Aktualisierungen überprüft werden soll. Die Angaben folgen der cron-Syntax. Wir wollen alle 15 Minuten eine Überprüfung des Repositories, was anschließend ein neuen Build ausgeführt, wenn sich der Inhalt geändert hat. Das erreichen wir mit folgender Zeile:

*/15 * * * *

Man kann seine Jobs auch so konfigurieren, dass nach einem Commit in unserem Repo automatisch ein Build ausgeführt wird, aber wir bleiben erstmal bei dieser einfachen Variante.

Bevor es mit der weiteren Einrichtung weitergeht übernehmen wir die Änderungen und starten den ersten Build. So kann festgestellt werden, ob der Zugriff auf die Softwarequelle gelingt oder ob die Konfiguration noch angepasst werden muss. Den Rest der Konfiguration werden wir ähnlich inkrementell fortführen, um die Sicherheit zu haben, dass unsere neuen Einstellungen funktionieren.

Jenkins & Github

Wer mit Jenkins Github-Projekte auschecken will, der sollte unter Jenkins Verwalten -> Jenkins Konfigurieren Benutzername und E-Mail für git konfigurieren, da Github keinen anonymen Checkout erlaubt.

Build-Schritte

Nach dem erfolgreichen Checkout können wir anfangen unsere Build-Schritte zu erstellen. Hierzu fügen wir in der Job-Konfiguration einen Shell-Build-Schritt hinzu, welchen wir nun nach und nach mit Leben füllen.

1. Virtualenv einrichten

Wir beginnen mit der Einrichtung einer isolierten Python-Umgebung mit virtualenv. Das sollte dazu auf dem Hauptsystem bereits installiert sein.

virtualenv pyenv
. pyenv/bin/activate

2. Pakete installieren

Anschließend installieren wir die für die Automatisierung mit Jenkins ein paar Pakete in unserer Python-Umgebung.

pip install pylint
pip install pep8
pip install nose

3. Requirements installieren

Bringt unser Repository eine Datei mit Abhängigkeiten mit, so installieren wir auch diese Abhängigkeiten:

pip install -r repo/requirements.txt

4. Pythonpath richtig setzen

Damit unsere Module importiert werden können, erweitern wir den PYTHONPATH:

PYTHONPATH=$WORKSPACE/repo:$PYTHONPATH
export PYTHONPATH

5. pylint

Die Ausgabe von pylint lässt sich mittels Violations-Plugin einbetten. Dieses wird in der Job-Konfiguration aktiviert und anschließend tragen wir dort als XML filename pattern das folgende ein: **pylint.txt

Damit das einen Effekt hat, müssen wir natürlich auch pylint im Build-Schritt aufrufen und die Ausgabe in die Datei pylint.txt umleiten. Und da pylint bei der Ausgabe von Meldungen nicht mit dem exit code 0 beendet wird, bauen wir uns dafür einen kleinen Workaround. Ohne den Workaround bricht der Build nach diesem Schritt ab, ohne die restlichen Schritte durchgeführt zu haben.

(pylint --output-format=parseable repo/ > pylint.txt) || echo 'pylint did not finish with return code 0'

Jenkins: Erste Ergebnisse von pylint

6. pep8

Auch für pep8 nutzen wir das Violations-Plugin und einen kleinen Workaround – aus dem gleichen Grund wie bei pylint. Als Dateinamens-Muster geben wir **pep8.txt ein und erweitern den Build-Schritt wie folgt:

pep8 repo/ > pep8.txt || echo 'pep8 did not finish with return code 0'

7. Tests durchführen

Zuletzt wollen wir Jenkins dafür nutzen, dass er automatisch unsere Tests ausführt. Dazu wird nose genutzt. In der Job-Konfiguration aktivieren wir die Veröffentlichung der JUnit-Testergebnisse und tragen dort die Standard-Ausgabedatei **nosetests.xml ein. An den Build-Schritt hängen wir folgendes an:

nosetests --with-xunit repo/tests/

Jenkins: Die Tests laufen auch

8. Zusammenfassung

Wir haben mit wenigen Schritten unser Projekt so konfiguriert, dass wir einige Aussagen über den Code-Stil bekommen und automatisch unsere Tests ausgeführt bekommen.

Der Build-Schritt sieht zusammengefasst so aus:

virtualenv pyenv
. pyenv/bin/activate

pip install pep8
pip install pylint
pip install nose

pip install -r repo/requirements.txt

PYTHONPATH=$WORKSPACE/repo:$PYTHONPATH
export PYTHONPATH

pylint --output-format=parseable repo/ > pylint.txt || echo 'pylint did not finish with return code 0'
pep8 repo/ > pep8.txt || echo 'pep8 did not finish with return code 0'
nosetests --with-xunit repo/tests/

Kleine Verbesserungen

Der Stand, den wir nun haben, ist erstmal lauffähig. Aber wir können uns mit ein paar Kleinigkeiten noch ein angenehmeres Leben bescheren.

Build-Anzahl beschränken

Da ich zu selten arg alte Ergebnisse anschauen möchte, beschränke ich die Aufbewahrung der Builds mit einem Haken bei Alte Builds Verwerfen und trage dort die Anzahl an aufzuhebenden Builds ein, z.B. 25. Auch kann man dort bestimmen, dass alle Builds älter als n Tage gelöscht werden. Kleiner Nebeneffekt ist, dass der Festplattenplatz nicht unendlich belegt wird.

Build-Schritte in Shellscripte packen

Wenn man zu dem Punkt gekommen ist, an dem man daran denkt einen Job zu kopieren, sollte man kurz innehalten und sich folgende Frage stellen: Wieviel Prozent meiner Build-Schritte werde ich einfach kopieren?

Meine Erfahrung ist, dass es oftmals mehr als 75% sind. Hier und da wird PYTHONPATH angepasst oder ein Schritt weggelassen, weil er keinen Sinn macht (z.B. weil es keine Tests gibt). Das sind alles Fälle, die man wunderbar durch ein Shell-Script abdecken kann. Der einfachste Weg ist die Build-Schritte in ein Shellscript zu kopieren und dann in Jenkins die vielen einzelnen Schritte durch den Aufruf des Shellscripts zu ersetzen.

Nachdem ich einmal die Erfahrung gemacht habe, welcher Aufwand es ist bei einer kleinen Änderung im Ablauf eine Reihe von Jobs anpassen zu müssen, bin ich mittlerweile froh, dass ich (fast) alles durch ein Shell-Script abdecken kann. Hier wird anhand diverser Bedingungen entschieden, welche Schritte nötig sind und mit welchen Optionen sie gestartet werden müssen.

Python-Pakete lokal laden

Für die eigenen Unabhängigkeit vom PyPI sollte man sich überlegen, dass man die zu installierenden Pakete lokal vorhält. Auch kann man nicht überall uneingeschränkt auf das Internet zugreifen, um sich von dort seine Pakete zu installieren. Andererseits kann es eine Zeit dauern, bis alle Pakete heruntergeladen und installiert sind (insbesondere, wenn virtualenv mit der –clean Option gestartet wird).

Möglichkeiten so etwas umzusetzen reichen von der einfachen Alternative alle Files lokal zu lagern und pip den kompletten Pfad mitzugeben (bspw. pip install /home/niko/nose-1.1.2.tar.gz) bis zum Aufsetzen eines eigenen, lokalen PyPI-Spiegels. Die Angabe des kompletten Pfads hat den Nachteil, dass man damit natürlich noch nicht die Requirements-Datei abdeckt.

Aufwändiger ist das Aufstellen eines eigenen PyPI-Mirrors. Ich denke aber, dass er mit der Anzahl der Nutzer immer nützlicher wird. Möglichkeiten gibt es viele, dazu kann man z.B. hier lesen, einen Blick auf die von pip  dargebotenen Möglichkeiten oder bereits fertige Module wie collective.eggproxy werfen. $Suchmaschine ist dein Freund

Und das wars auch schon. Ich bin auf Anregungen und Meinungen gespannt

Nun frage ich mich, ob Microsoft in Zukunft auch für andere Features bezahlt werden will. Könnte durchaus eine Ergänzung in einem Windows-App-Store sein, oder nicht?

Wie siehts eigentlich aus mit alternativen Playern unter Windows 8. Ist es eventuell schon genug, dass man sich eine aktuelle Version von z.B. VLC installiert?

Zu guter letzt kann ich eigentlich nur darauf verweisen, dass sowas einerseits die Folgen von geschlossenen und unfreien Standards sind und anderseits, ja andererseits, passiert mir sowas bei Linux nicht

Implementieren kann man es so:

class Borg:
    _state = {}
    def __init__(self):
        self.__dict__ = self._state

Hier noch ein Beispiel zum Verständnis:

>>> b = Borg()
>>> b.foo = 42
>>> b.__dict__
{'foo': 42}
>>> c = Borg()
>>> c.__dict__
{'foo': 42}
>>> c.cheese = True
>>> b.cheese
True
>>> b == c
False

Wie man sieht, teilen sich die Instanzen zwar ihren Zustand, sind aber nicht das gleiche Objekt.

If you hire people just because they can do a job, they’ll work for your money. But if you hire people who believe what you believe, they’ll work for you with blood and sweat and tears.
-Simon Sinek

via Journal of An Open Sourcee

Nun habe ich gesehen, dass man diese Einstellung auch bequem über die KDE Systemeinstellungen vornehmen kann. Dort gibts unter Fensterverhalten -> Fensterverhalten -> Verschieben den Punkt “Ränder bei maximierten Fenstern anzeigen”. Super

Hier eine kleine Auswahl:

• A-Team (die Serie)
• The Big Lebowski
• Die Hard (PHP)
• Die Hard (Shell)
• Fear and Loathing in Las Vegas
• Walk the Line

Vermutlich hatte deshalb auch David Goodgers Code Like a Pythonista: Idiomatic Python einen so großen Einfluss auf mich. Ich kehre immer wieder gerne für ein paar Minuten dorthin zurück, gehe in mich und anschließend beschwingt zurück an meine Arbeit.

BrowserQuest: "You feel the Power of Firefox"

Leider läuft es bei mir nur im Firefox, unter Chromium kommt keine Verbindung zustande. Macht aber nix, ist nämlich eher kurzweilig.

Zu Beginn gabs spontane Vorträge – mal mit technischer Unterstützung, mal ohne. Die Vortragenden habe gute Arbeit geleistet und Ihre Themen –  Twitters Bootstrap, Abstracte Datentypen,  Selenium – so dargestellt, dass man selbst als Themenfremder nicht komplett abgehangen wurde. Besonders faszinierend fand ich die abstrakten Datentypen, auch wenn ich bis jetzt keine Anwendungsfall dafür habe. Bedeutet aber vermutlich, dass ich mir mal Eiffel anschauen muss.

Der zweite Teil des Abends war geprägt durch Hands On. Es sollte eine Code Kata im Team – als Pair Programming – gelöst werden. Für mich war beides das erste Mal und ich fands definitiv interessant. Beim Pair Programming habe ich gedacht, dass man sich mehr an der Tastatur abwechselt, aber es war eher so, dass man einer programmierte und vom Rest des Teams Input zur weiteren Vorgehensweise kam. Für die Roman Numeral Kata hatten wir eine Stunde Zeit, natürlich durfte auch danach noch weitergemacht werden
Wir sind nicht fertig geworden, aber lehrreich fand ich die Zeit auf jeden Fall – ein Erfolg!

Den Rest des Abends verbrachten wir mit Smalltalk über dieses und jenes, ein gemütlicher Abschluss.
Es ist schön zu sehen, dass die Gruppe wächst und weiterhin offen für alle bleibt. Deshalb freue ich mich schon auf das nächste Treffen