inside.pokefans

Packt sqlmap wieder ein - ihr habt doch nicht wirklich gedacht, dass ich euch hier beibringe, wie man Pokefans zerlegt. Nein, wir befassen uns heute mit der guten Definiton von "hacken" - programmieren. Aber wenn ich eine Chance auf Clickbait sehe, dann muss ich sie schon nutzen, irgendwie... :D

Pokefans ist ja ein recht umfangreiches Projekt, und man braucht ein bisschen Startwissen, um hier mitmachen zu können. Bei knapp 1000 Dateien im Repository verliert man vielleicht auch ein bisschen den Überblick. Dafür ist dieser Blogpost da.

Die Struktur des Repositories habe ich ja schon vor einem Jahr (runterscrollen!) beschrieben. Daran hat sich nichts geändert. Vielleicht solltest du das jetzt nochmal lesen. Seither hat sich ein bisschen was getan, die Struktur stimmt aber noch. Um das hier jetzt etwas einfacher zu halten, führe ich den Begriff der Magie ein. Immer, wenn das Verständnis der Mechanik nicht wirklich notwendig ist, um zu verstehen, dass die so ist, wie sie ist, passieren Dinge automagisch oder sind einfach hochgradig uninteressant. Diese Worte werde ich hier noch ein paar mal Verwenden :) Selbstverständlich hat alles einen guten Grund, warum es so funktioniert, wie es funktioniert - vermutlich verwirrt dich das am Anfang aber nur, weil es schwer ist, sich das vorzustellen, ohne das gesamte Framework sehr tief zu kennen. Begnügen wir uns also mal ab und an damit, dass Dinge mit Magie passieren - schließlich ist ja jede hinreichend fortgeschrittene Technik von Magie nicht zu unterscheiden :)

Was setze ich hier voraus? Du solltest grundlegendes Verständnis von folgenden Begriffen haben. Wenn nicht, geh, und schlag' sie nach.

• Klasse
• Konstruktor
• Methode
• while
• for
• foreach
• if
• else
• try
• catch

Nachdem wir diese grundsätzlichen Sachen jetzt geklärt hätten, können wir ja anfangen!

Schauen wir uns mal einen typischen Konstruktor an. Den hier zum Beispiel.

public HomeController(IBreadcrumbs crumbs, Entities entities, Cache c)
        {
            this.breadcrumbs = crumbs;
            _entities = entities;
            cache = c;
        }

Im Konstruktor bekommt dein Controller ein paar interessante Sachen. Hier bekommst du eine Klasse, die Breadcrumbs verwaltet, den Datenbanklayer (Entities) und den Cache. Das ganze passiert automagisch, wir speichern uns das weg, damit wir das nachher in den Klassenmethoden verwenden können. Falls du dir das nicht merken kannst: Einfach Kopierpaste verwenden. Damit machst du sicher nichts falsch.

Das Wichtigste aus dem Konstruktor sind dabei die Entities. Die sind deine Schnittstelle zur Datenbank. Jede Klasse von hier, die nicht im Migrations-Ordner ist und nicht Entities heißt entspricht einer Tabelle in der Datenbank. Dass sich das zusammenfindet stellt hier Magie sicher. Wir können uns damit begnügen, dass es in der Regel so ist (da gibt's zwar ein, zwei Ausnahmen, aber die sind hochgradig uninteressant).

Wie benutze ich das jetzt? Nun, die Entities haben für jede Datenbanktabelle eine Eigenschaft. Da sind die Daten drin. Und die können wir uns jetzt rausholen. Wenn ich z.B. alle Benutzer haben möchte, deren Name ein 'x' beinhaltet, dann sieht das so aus:

    List<User> users = _entities.Users.Where(x => x.Username.Contains('x')).ToList();

oder kürzer:

    var users = _entities.Users.Where(x => x.Username.Contains('x'));

Was da genau der Unterschied ist, ist für uns erstmal hochgradig uninteressant. Man sollte jedoch beachten, dass die letztere Variante nicht direkt an eine View übergeben werden kann, da müssen wir dann beim Übergeben noch ToList() aufrufen.

Jetzt kann ich auch sagen, ich will nicht eine Liste von Benutzern, sondern ich will einen bestimmten Benutzer, z.B. anhand seiner UserID haben. Das geht so:

    User user = _entities.Users.FirstOrDefault(x => x.UserId == 42);

Fertig.

Innerhalb der Klammer steht ein sogenannter Lambda-Ausdruck. Das ist nichts anderes als die kompakte Schreibweise einer Funktion, die auf jeden Eintrag der Datenbank angewandt wird. Kann man sich so vorstellen - aus dem Lambda aus dem vorherigen Beispiel könne man z.B. das hier machen:

    bool lambda(User x) {
        return x.UserId == 42;
    }

Wenn der Vergleich true wird, dann landet das Element in der Liste, wenn nicht, dann halt nicht. Eigentlich recht einfach, oder?

Wenden wir uns weiterer Magie zu. Jede URL mappt auf eine bestimmte Methode. Wie das passiert, besprechen wir nachher, im Moment begnügen wir uns damit, dass wir gerade eine URL aufgerufen haben, die hier rauskommt. Auch das passiert für uns automagisch und die Details sind hochgradig uninteressant - vorerst.

Wichtig sind hier erstmal zwei Dinge:

1. Der Rückgabewert der Methode ist vom Typ ActionResult. Das ist eigentlich immer so. Der Name ist irrelevant, sollte aber halbwegs beschreibend sein.
2. In Zeile 15 haben wir ein return mit einem ewig langen Pfad drin. Dieser Pfad gibt an, wo die View (also die Anzeigevorschrift) für diese Methode ist. Dort ist dann das HTML-Template, das die Daten aus dem Controller in HTML verwandelt.

Wenn der Computer also das abarbeitet und beim return ankommt, landen wir dann hier. Das ist die dazugehörige View. Findest du den Pfad wieder? Ja? Gut. Der Inhalt hier ist auch nicht sonderlich spannend, zeigt aber, wie die Abfolge grunsätzlich läuft: Url -> Controller-Methode -> View -> fertig.

Jetzt ist so eine statische Seite relativ langweilig. Ich will Daten übergeben! Dazu schauen wir uns ein etwas komplizierteres Beispiel an - etwa das hier. Das hier ist ein Auszug aus der neuen Fanart-Verwaltung. Halten wir mal folgendes fest:

1. Zeile 47 holt sich Daten aus der Datenbank. Wie genau - hochgradig uninteressant für den Moment. Wir holen uns alle Fanarts mit zugehörigen Tags, die vom gerade angemeldeten Benutzer hochgeladen wurden, sortiert nachdem Zeitpunkt des Hochladens, neuere zuerst.
2. Zeile 48 holt die Namen der Fanart-Kategorien aus dem Cache. Das geht schneller als der Datenbankzugriff. Details dazu sind wieder hochgradig uninteressant.
3. Zeile 50 übergibt die Daten an die View. Preisfrage: Worin besteht denn der unterschied zur vorherigen Zeile?

Da kommen wir dann hier raus. Gerendert sieht das dann z.B. so aus. Quellcode.

Dabei geben wir in der View in Zeile 2 den Typ der Variable an, die wir vorhin übergeben haben - hier eine Liste. Diese Variable heißt innerhalb der View Model. Der geneigte Leser möge jetzt über folgende Fragestellungen nachdenken:

• Wo fängt die View im Quellcode an, wo hört sie auf?
• Wo sind die Schleifen hinverschwunden? Was haben sie generiert?
• Was macht Url.Action(...)?
• Was könnte @variable machen?

Hier die Auflösung:

• Die View geht von Zeile 70 bis Zeile 104.
• Die äußere Schleife hat den Code von Zeile 82 bis 102 generiert. Wäre mehr als eine Fanart hochgeladen, würde sich dieser Block entsprechend wiederholen.
• Die innere Schleifen haben Z85 - 89 respektive Z93-98 generiert. Die zweite Schleife macht dabei nichts anderes, als die Fließkommazahl der Bewertung als Sterne darzustellen.
• Url.Action(...) generiert einen Link. Wir geben dabei Klasse und Methode des Ziels an, die URL wird anhand der Mappingtabelle gefunden
• @variable gibt Variablen aus - und zwar XSS-Sicher, alles HTML wird escaped, damit es keinen Schaden anrichten kann.

Wie mappe ich jetzt eine URL zu einer Methode in einer Klasse? In unserem Beispiel sind wir im ManageController und unsere Methode heißt Index. Das zugehörgige Mapping gibts hier:

            context.Routes.Add("fanartManage", new DomainRoute(
                            "fanart." + ConfigurationManager.AppSettings["Domain"],
                            "verwaltung",
                            new { action = "Index", controller = "Manage" },
                            dataTokens
                ));

Auch hier passiert wieder viel automagisch, was uns nicht weiter kümmern braucht. Wichtig ist nur folgendes:

1. Der Name - hier fanartManage - muss eindeutig sein. Keine Sorge, es fliegt dir um die Ohren, wenn es nicht eindeutig ist.
2. Die korrekte Subdomain muss angegeben werden.
3. Die Url nach dem / muss angegeben werden. Da wir hier bei http://fanart.pokefans.rocks/verwaltung/ rauskommen wollen, ist das nur "verwaltung" (beachte, dass ich keinen abschließenden / gesetzt habe!).
4. Action ist der Name der Methode, die aufgerufen werden soll, wenn jemand diese URL ansurft. Controller ist die Klasse, in der sich die Methode befindet. Beachte, dass die Klasse in Wahrheit ManageController heißt und sich im Unterordner "Controllers" der entsprechenden Area befindet. Das muss so sein, da fährt die Eisenbahn drüber.
5. die DataTokens musst du einfach reinkopieren. Was die machen, ist hochgradig uninteressant.

Tja, dann bleibt mir auch nicht mehr viel zu sagen, außer: happy hacking. Und falls es noch fragen gibt... einfach melden. Es gibt keine dummen Fragen.

Nachdem ich jetzt einige Zeit mit programmieren unter Arch Linux verbracht habe - wie einige aufmerksame Leser vielleicht durch unseren IRC-Channel mitbekommen haben - will ich hier kurz meine Erfahrungen damit niederlegen. Vielleicht kann ja der ein oder andere damit was anfangen - und am besten Nachmachen.

Vorbereitungen

Damit unser Zeug überhaupt unter Linux läuft, braucht man ein aktuelles Mono. Aktuell heißt in dem Fall: mindestens Version 4.3. In den Repositories ist derzeit 4.0.2 - und das ist aus mehreren Gründen zu alt:

1. Ihm fehlt mein Patch für System.Web
2. es hat noch nicht das Reference-Source System.Data (und ist damit inkompatibel zu Glimpse)

Was also tun? Die Antwort hierauf ist einfach: ein parallel Mono environment aufsetzen! Leider ist die dazugehörige Anleitung nicht mehr ganz aktuell, daher mag ich das ganz kurz zusammenfassen. Vorausgesetzt wird ein bereits installiertes mono-complete aus den Repositories deiner Linux-Distribution.

mono kompilieren

git clone https://github.com/mono/mono
cd mono
./configure --prefix=/opt/mono
make
sudo make install

Wir holen uns Mono von github, konfigurieren es den Präfix /opt/mono zu verwenden, bauen es und installieren es nach /opt/mono.

Das dauert jetzt seine zeit. Hol dir inzwischen einen Kakao und ein paar Kekse. Alles fertig? Gut. Dann können wir ja weitermachen. Jetzt kompilieren wir xsp, gnome-sharp und gtk-sharp. Dazu wechseln wir zu allererst ins Parallel Mono Environment:

#!/usr/bin/env bash

MONO_PREFIX=/opt/mono
GNOME_PREFIX=/opt/gnome
export DYLD_FALLBACK_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_FALLBACK_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
export PATH=$MONO_PREFIX/bin:$PATH

Speichere dieses Skript als mono-parallel.sh ab und source es. Und zwar so (direktes Aufrufen bringt nichts):

source mono-parallel.sh

Mono müsste sich jetzt als Version 4.3 (oder neuer) melden, wenn nicht, hast du etwas falsch gemacht:

mono --version

Passt alles, können wir fortfahren:

git clone https://github.com/mono/gnome-sharp
cd gnome-sharp
git checkout 2.24.1
./bootstrap-2.24 --prefix=/opt/mono
make
sudo make install

Genauso verfahren wir mit gtk-sharp:

git clone https://github.com/mono/gtk-sharp
cd gtk-sharp
git checkout 2.24.1
./bootstrap-2.24.1 --prefix=/opt/mono
make
sudo make install

Zu guter Letzt kommt jetzt noch xsp:

git clone https://github.com/mono/xsp
cd xsp
./configure --prefix=/opt/mono
make
sudo make install

Jetzt sind wir Startklar. Überprüfe, ob monodevelop startet, indem du es direkt in der Kommandozeile aufrufst. Passt alles, kannst du es wieder schließen und dieses Skript nach /usr/bin/monodevelop-gitmono speichern:

#!/usr/bin/env bash

MONO_PREFIX=/opt/mono
GNOME_PREFIX=/opt/gnome
export DYLD_FALLBACK_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_FALLBACK_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
export PATH=$MONO_PREFIX/bin:$PATH

monodevelop

Damit startest du monodevelop mit dem guten Mono einfach per Doppelklick auf das Skript oder Aufruf von

monodevelop-gitmono &

aus der Kommandozeile.

Wie arbeitet es sich jetzt mit monodevelop?

Nun, ich bin Visual Studio gewöhnt. Man merkt, dass VS das wesentlich ausgereiftere Produkt ist, aber das ist auch nicht weiter verwunderlich. Monodevelop steht mir aber nicht im Weg herum, nachdem ich alle Keybindings auf meine gewohnten angepasst habe, den Whitespace und Codestyle richtig gestellt hatte, lief alles wie am Schnürchen. Monodevelop kommt mir - bis auf die Tatsache, dass es Swapping noch weniger verträgt als Visual Studio - sogar einen tacken schneller vor. Aber da kann ich mich auch täuschen.

Sehr angenehm ist auch, dass xsp4 sich nicht um irgendwelche Hostnamen schert, wie der IISExpress oder der große IIS. Eine Fehlerquelle weniger.

Etwas nervig ist nur, dass z.B. für die EntityFramework-Migrationen keine direkte Integration gegeben ist. Unser dbtool ist funktional noch nicht gänzlich äquivalent. Migrationen müssen auf eine spezielle Weise im Projekt eingetragen sein, damit alles funktioniert. Ich weiß nicht, wie man das in der GUI macht, daher muss ich bis jetzt immer nach dem Hinzufügen einer Migration den Foo selbst in der Projektdatei ausbessern. Das kann man aber fixen; so kompliziert ist das nicht (das sind alles XML-Dateien). Man müsste es nur implementieren. Falls du helfen willst, melde dich einfach bei mir.

So long, Delirium

Hallo zusammen,

ab und an werde ich jetzt Watch Me Code-Sessions auf dem Pokefans-Twitch-Kanal abhalten. Da könnt ihr mir beim programmieren zusehen (live, in Farbe und mit Stereo!) sowie Fragen stellen, die ich dann hoffentlich beantworten kann. Wer also immer schonmal wissen wollte, wie so Projekte eigentlich entstehen, einfach einschalten:

http://www.twitch.tv/pokefansnet

Cheers,

Delirium

Update:

Die Codefiles der heutigen Session sind jetzt auf Github. Danke fürs Zusehen!

Vor zwei Wochen stellten wir euch das neue Entwicklungskonzept von Pokefans.net vor. Nun ist es endlich soweit! Ab sofort wird der Entwicklungsprozess öffentlich auf der open-source-Plattform GitHub durchgeführt. Dies bedeutet nicht nur, dass ihr nun den aktuellen Stand stets verfolgen könnt, sondern ihr könnt Pokefans nun auch auf technischer Seite aktiv vorantreiben!

Das Repository des neuen Kerns "Mighty Milotic" findet ihr hier auf GitHub.

Wer gleich loslegen will und sich den bestehenden Code zu Gemüte führen möchte, der braucht zunächst ein paar Tools. Eine Anleitung für die verschiedenen Systeme haben wir auf dieser Seite für euch zusammengestellt. Wie an allen anderen Stellen steht es euch hier natürlich frei, die Liste zu erweitern oder Stellen zu dokumentieren, an denen es Probleme gab. Auf diese Weise könnt ihr zukünftigen Mitarbeitern helfen, die an der gleichen Stelle Probleme hatten.

Damit die Entwicklung reibungslos vorangehen kann gibt es natürlich ein paar Spielregeln, an die sich jeder Entwickler halten muss. Diese wollen wir im Folgenden kurz anreißen. Als allgemeine Orientierung kann euch der bestehende Code dienen.

• Schreibt guten und dokumentierten Code! Bei Pokefans handelt es sich um ein großes Projekt, dessen Code über einen langen Zeitraum eingesetzt und gewartet werden soll. C# bietet die Möglichkeit, Klassen und Funktionen durch XML-Kommentare zu dokumentieren. Hier wäre es gut, wenn diese zu jeder Funktion existieren. Zu detaillierten Style-Kriterien des Codes wird in den nächsten Tagen noch ein Dokument in das Repository geladen, indem ihr genauere Informationen findet.
• Jeder von euch kann neue Features hinzufügen oder verbessern, allerdings müssen diese zunächst durch ein Mitglied des Entwicklerteams überprüft werden. Dies geschieht, indem ihr euch zunächst das Projekt auf GitHub klont. Nachdem ihr dann die Änderungen vorgenommen habt, könnt ihr einen Pull-Request einreichen. Dieser kann dann in das bestehende System übernommen werden.
• Alle Programmteile müssen sorgfältig getestet werden. Wir setzen bei der Entwicklung auf Unit-Tests und im Idealfall sollte jede Funktion durch einen Test abgesichert werden. Dies verhindert, dass die Arbeit an einer Stelle unabsichtlich etwas anderes zerstört.
• Wenn ihr einen Fehler findet, so könnt ihr in ihm Issue-Tracker von GitHub eintragen. Es steht euch natürlich frei, diesen auch selbst zu beheben. In diesem Fall wäre es toll, wenn dazu gleich ein Test geschrieben wird, sodass dieser Fehler beim nächsten Mal abgesichert ist!

Selbst wenn ihr noch dabei seid, das Programmieren zu lernen, ist dies kein Problem! Wir stehen euch im Forum oder im IRC-Chat bei Fragen zur Verfügung.

In den folgenden Wochen werden wir den bestehenden Kern erweitern und auch weitere Dokumentationen veröffentlichen. Diese findet ihr dann zum einen hier im Blog, aber auch auf GitHub im Repository.

Wie immer könnt ihr euch bei Fragen gerne an uns wenden, entweder direkt hier per Kommentar oder per PN im Forum.

~Birne

Nun, hier sind wir wieder. Nachdem bei der großen Umfrage sich doch einige einen development-Blog gewünscht haben, werden wir hier also etwas aus dem Nähkästchen plaudern.

Was erwartet euch also hier? Nun, das wissen wir selbst noch nicht so genau. Wir wollen euch jedenfalls Einblicke in die aktuelle Entwicklung an Pokefans geben. Etwas über dieses und jenes schreiben, die Architektur etwas erklären. Wahrscheinlich wird es oft sehr technisch. Aber technisch ist gut.

Damit das Ganze funktioniert, müsst ihr natürlich mitmachen. Wer einen Themenvorschlag hat, immer her damit. Das hier ist ein Service für eure Informationslust. Je genauer ihr uns sagt, was euch interessiert, desto besser werden wir unsere Blogeinträge darauf abstimmen können ;-)

~ Delirium