/**
 * Returns the most recent, active accounts
 * 
 * @param int $count
 * @return \Doctrine\Common\Collections\ArrayCollection
 */
 public function loadLatestAccounts($count = 8)
 {
     $qb = $this->_entityManager->createQueryBuilder();

     $qb->select('a')
         ->from('Apro\Entities\User', 'a')
         ->setMaxResults($count)
         ->where($qb->expr()->eq('a._status', ':status'))
         ->orderBy('a._created', 'DESC')
         ->setParameter('status', 1);

        return $this->_secureCollectionResult($qb->getQuery()->getResult());
 }

Und nun dieselbe Abfrage mit Hilfe von lift und rogue:

val users = User where (_.status eqs 1) orderDesc(_.created) fetch(8)

WHOOOOOOOOT?!
Ja, so einfach kann es sein, von der Ausgabe mal ganz zu schweigen, die sieht aehnlich aus.

<ul class="pagination">
    <li class="disabled">
        <a href"#">First Page</a>
    </li>
    <li class="active">
        <a href="#">1</a>
    </li>
    <li>
        <a href="#">2</a>
    </li>
    <li>
        <a href="#">2</a>
    </li>
</ul>

Natuerlich gehe ich davon aus, dass in den hrefs jeweils Links zu den Pages stehen, es sei denn der Link ist “disable” oder “active”. D.h. hier gibt es keinen Grund zu verlinken, da wir uns in diesem Fall schon auf der Seite befinden. Soweit so gut. Wie funktioniert nun die Pagination in einem Liftweb Projekt?

Zunaechst der Code-Ausschnitt fuer das Snippet, das eine Pagination enthaelt:

class MySnippet extends StatefulSnippet with PaginatorSnippet[MyModel] {

}

Indem man das eigene Snippet mit einem PaginationSnippet vom Typ MyModel verwendet, laesst sich die eingebaute Logik fuer Pagination verwenden. MyModel sind dabei jeweils die Listenelemente, die man anzeigen moechte. In der HTML-Datei wuerde der Aufruf nun so aussehen (Designerfriendly Variante, die ich bevorzuge):

<div class="lift:MySnippet.paginate" xmlns:nav="navigate">
    <nav:first />
    <nav:prev />
    <nav:allpages />
    <nav:next />
    <nav:last />
</div>

Lift nimmt einem hierbei viel Arbeit ab und bindet “nav” zur entsprechenden Methode. Was nun allerdings ausgegeben wird sind reine Links bzw. Text. D.h. uns fehlt die ul und li Struktur, die wir zum gestalten bei Bootstrap benoetigen. Eine nahe liegende Idee zur Loesung sieht so aus:

<div class="lift:MySnippet.paginate" xmlns:nav="navigate">
    <ul class="pagination">
        <li>
            <nav:first />
        </li>
        <li>
            <nav:prev />
        </li>
        <li>
            <nav:allpages />
        </li>
        <!-- ... -->
    </ul>
    
</div>

Das ist zwar einfach, funktioniert aber aus zwei Gruenden nicht:
1. Die inaktiven und ausgewaehlten Seiten kann man nicht speziell markieren.
2. Lift verlinkt die inaktiven Seiten nicht, sondern gibt nur Text aus. D.h. die Styles von Bootstrap greifen hier nicht.

Meine Loesung sieht so aus, dass man die pageXml Methode im eigenen Snippet wie folgt ueberschreibt:

override def pageXml(newFirst: Long, ns: NodeSeq): NodeSeq = {

  var pageAccess = -1
  try {
    pageAccess = ns.text.toInt
  } catch {
    case _ : java.lang.NumberFormatException => None
  }

  if(first==newFirst || newFirst >= count || newFirst < 0)
    // In case of current page we show the active style
    if (curPage + 1 == pageAccess)
      <li class="active"><a href="#">{ns}</a></li>
    else
      <li class="disabled"><a href="#">{ns}</a></li>
  else
    <li><a href={pageUrl(newFirst)}>{ns}</a></li>
}

Man zieht die li Elemente in das Snippet, um auch die Styles richtig setzen zu koennen. Dazu nutze ich noch einen recht unschoenen Cast, um an die Seitenzahl zu gelangen. Die inaktiven und selektierten Seiten verlinken ich nun, um Bootstrap zu sagen, dass diese Elemente zur Pagination gehoeren (was auch unschoen ist). Im HTML Part sieht das nun so aus:

<div class="lift:MySnippet.paginate" xmlns:nav="navigate">
    <ul class="pagination">
        <nav:first />
        <nav:prev />
        <nav:allpages />
        <!-- ... -->
    </ul>
</div>

Damit hat man die Pagination des Bootstrap Frameworks und Liftweb Pagination kombiniert. Ich hoffe, dass es hilfreich war. Verbesserungen sind gerne willkommen!

dependencies {
    // Include liftweb dependencies here

    // Logging
    compile "org.slf4j:slf4j-log4j12:1.6.4"
}

Ich hoffe, dass ich euch ein wenig helfen konnte.

Lift bietet eine super Möglichkeit zwischen einer Production und einer Development Umgebung zu unterscheiden. Dies erreicht man indem man zwei Properties Dateien im resources Verzeichnis anlegt: default.props und production.default.props

Der Inhalt ist dabei recht simpel und enthält jeweils nur die Hosts, die wir verwenden möchten. In der lokalen Entwicklungsumgebung sollte es also etwas sein, das lokal editierbar ist und in der Production-Konfiguration evtl. ein CDN (s.u.)

src.host.css=http://localhost:8080/css
src.host.js=http://localhost:8080/js

src.host.css=http://cdn.css.mywebapp.com
src.host.js=http://cdn.js.mywebapp.com

Lift verarbeitet diese Dateien automatisch. Die Entscheidung, ob die eine oder andere Datei gewählt wird, trifft Lift anhand des -Drun.mode Arguments des Servers.
Jetzt geht es also nur noch darum diese Konfigurationen zu verarbeiten. Das Ziel sollte sein, dass wir recht einfach im View-Skript definieren können welche Datei eingebunden werden soll. Und das geschieht (“Designer-Friendly”) in etwa so:

<span class="lift:ResourceSnippet.css?file=lib/core.css;media=screen"></span>

Wie ihr sehen könnt, habe ich zwei Parameter an das Snippet übergeben, file und media. Und als Ergebnis möchten wir Folgendes:

<link href="http://localhost:8080/css/lib/core.css" type="text/css" media="screen" />

Was nun also fehlt ist der Snippetcode:

object ResourceSnippet {
  def css(xhtml: NodeSeq): NodeSeq = {
    // File we want to be included
    val file : String =  S.attr("file") openOr ""

    // Media attribute
    val media : String = S.attr("media") openOr ""

    PCDataXmlParser.apply(cssFile(file, media)).get
  }

  def cssFile (file : String, media : String) : String = {
    String.format("<link href="%s/%s" rel="stylesheet" type="text/css" media="%s"/>",
                  Props.get("src.host.css").getOrElse(""),
                  file,
                  media)
  }
}

In dem Snippet definieren wir zwei Methoden (es geht auch in einer). Die Methode cssFile erstellt uns einen String, der dem Endergebnis entspricht. Das Aufrufen von ResourceSnippet.css bewirkt, dass die Parameter ausgelesen werden und der erstellte String aus der Methode cssFile in ein valides HTML (mit Hilfe des PCDataXmlParser) überführt wird. Für JS Dateien ist das Vorgehen analog. D.h. wir erweitern unseren Snippet-Code wie folgt:

object ResourceSnippet {
  def css(xhtml: NodeSeq): NodeSeq = {
    // File we want to be included
    val file : String =  S.attr("file") openOr ""

    // Media attribute
    val media : String = S.attr("media") openOr ""

    PCDataXmlParser.apply(cssFile(file, media)).get
  }

  def cssFile (file : String, media : String) : String = {
    String.format("<link href="%s/%s" rel="stylesheet" type="text/css" media="%s"/>",
                  Props.get("src.host.css").getOrElse(""),
                  file,
                  media)
  }

  def jscFile (file : String, id : String) : String = {
    String.format("<script src="%s/%s" rel="stylesheet" type="text/javascript" id="%s"></script>",
      Props.get("src.host.js").getOrElse(""),
      file,
      id)
  }

  def jsc (xhtml : NodeSeq): NodeSeq = {
    val file : String = S.attr("file") openOr ""
    val id : String = S.attr("id") openOr ""
    
    PCDataXmlParser.apply(jscFile(file, id)).get
  }
}

Der Aufruf des Snippets für JS Dateien sieht dann so aus:

<span class="lift:ResourceSnippet.js?file=lib/jquery.js;id=jquery"></span>

Recht einfach, oder? Ich wünsche viel Spaß beim Ausprobieren!

Nehmen wir also an, dass man einen physikalischen Server hat, den man bereits zur besseren Auslastung mit 3 virtuellen Hosts ausgestattet hat (vm-a, vm-b, vm-c). Die vm-c nehmen wir als Router/Load Balancer für eine Webapp und für die Auslieferung vom statischen Content (css oder js z.B.). Auf der vm-a möchten wir nun zwei Jetty Server laufen lassen, die eine Webapp ausliefern und durch den Nginx von der vm-c angesprochen werden. Die zusätzliche vm-b könnte in diesem Fall für Datenbanken oder NoSQL bereitstehen (also an dieser Stelle nicht weiter wichtig).

Idealerweise wäre natürlich eine Installation über den Synaptic Paket Manager, was allerdings in diesem Fall eher komplizierter ist. Ich zeige hier den etwas “dreckigeren” Weg, der aber zum Einstieg einfacher ist (meine subjektive Wahrnehmung). Deshalb loggt man sich nun per ssh auf seine VM ein. Für ein wenig Struktur legt man ein Verzeichnis “server” und lädt in dieses eine Jetty Variante herunter (ich verwende in der Beispielinstallation die Version 6.1.26). Mit unzip kann man das heruntergladene ZIP-Paket entpacken. Das sieht nun auf der Console so aus:

mkdir server; cd server
wget http://dist.codehaus.org/jetty/jetty-6.1.26/jetty-6.1.26.zip
unzip jetty-6.1.26.zip

Nun hat man einen lauffähigen Jetty Server, den man ohne Bedenken starten könnte. Wir möchte allerdings mehrere, also erstellen wir zwei Verzeichnisse jetty-a und jetty-b. In diese legen wir jeweils eine Kopie des entpackten Server-Packages. Diese werden unsere getrennten Server sein.

mkdir jetty-a
mkdir jetty-b

cp -R jetty-6.1.26 jetty-a/
cp -R jetty-6.1.26 jetty-b/

Theoretisch kommt man auch mit einer Installation aus. D.h. man müsste an dieser Stelle den Ordner nicht kopieren. Ich persönlich finde es jedoch übersichtlicher und auch strikter getrennt. So kann man sich in der Konfiguration an einer Jetty Variante auslassen ohne die andere zu beeinflussen.

Wenn man nun z.B. versucht jetty-a zu starten und danach jetty-b, erhält beim Start von jetty-b die Meldung, dass bereits ein Jetty-Prozess läuft. das liegt an mehreren Ursachen. Eine davon ist die Server ID in der etc/jetty.xml Datei. D.h. das ist die erste Änderung, die wir vornhemen. Dazu öffnet man z.B. mit nano jeweils die jetty.xml Dateien der einzelnen Varianten und ändern die Server ID in ServerA bzw. ServerB (Speichern nicht vergessen, bei Nano STRG+O). Zusätzlich vergeben wir in dieser Datei auch den Standard Port für die jeweilige Variante (für jetty-a 9090 und für jetty-b 9191).

sudo nano jetty-a/jetty-6.1.26/etc/jetty.xml
sudo nano jetty-a/jetty-6.1.26/etc/jetty.xml

Dies alleine wird jedoch nicht reichen. Das Startskript unter bin/jetty.sh schaut bzgl. laufender Jetty Prozesse in der Datei /tmp/jetty.pid nach, ob Instanzen von Jetty aktiv sind. An dieser Stelle müssen wir eingreifen und diese Logik abändern, sodass das Startskript für jetty-a in der Dateie /tmp/jetty-a.pid nachschaut und das Skript für jetty-b entsprechend in /tmp/jetty-b.pid. Dazu öffnet man jeweils die Datei bin/jetty.sh und fügt folgende Zeilen direkt vor der ersten unkommentierten Zeile ein (hier als beispiel für jetty-a, usernamen bitte entsprechend ersetzen):

JETTY_HOME=/home/{{username}}/server/jetty-a/jetty-6.1.26/
JETTY_PID=/tmp/jetty-a.pid

Diese einfache Konfiguration reicht aus, um bei jetty Varianten zu starten. zunächst jetty-a:

sh /home/{{username}}/server/jetty-a/jetty-6.1.26/bin/jetty.sh start

Und danach jetty-b:

sh /home/{{username}}/server/jetty-b/jetty-6.1.26/bin/jetty.sh start

Ich habe in diesem Szenario ein Load Balancing vorgeschlagen. Denkbar ist jedoch auch eine Staging Umgebung oder ein Beta-Server, o.ä.
Wie auch immer, ich hoffe, dass es euch weiter hilft und wünsche viel Spaß beim Ausprobieren!

Zunächst brauchen wir eine Properties Datei, die ich in der Regel im root Verzeichnis unter dem versteckten Ordner .properties ablege. Den Namen kann man sich im Grunde frei ausdenken, ich verwende an dieser Stelle nexus-credentials.properties-hidden. Der Inhalt kann dann in etwa so aussehen:

user.name=privatenuxus
user.password=privatenuxuspassword

Im Gralde build File kann man nun im Groovy Style eine kleine Hilfmethode schreiben, die einem diese Datei ausliest und direkt in eine Properties-Struktur ausliest:

...
def loadRepositoryProperties() {
    repositoryProperties = new Properties()

    file(".properties/nexus-credentials.properties-hidden").withReader { reader ->
        repositoryProperties.load(reader)
    }

    return repositoryProperties
}
...

Nun lässt sich der Zugriff auf das private Nexus Repo bequem steuern. Dazu konfiguriert man zunächst die Properties und verwendet diese dann an entsprechender Stelle. Easy, oder?

def propertiesRepository = loadRepositoryProperties()

repositories {
    maven {
        name "My private Nexus"
        credentials {
            username = propertiesRepository['user.name']
            password = propertiesRepository['user.password']
        }
        url "http://my.privatenexus.com/content/repositories/release/"
    }
}

Unter der Url gibt man natürlich die URL zum repo an, ich habe hier nur einen Phantasienamen verwendet.

Falls man nun auch noch GIT im Einsatz hat, bietet sich an dieser Stelle an die Properties Files aus der Verwaltung zu nehmen, damit diese nicht versehentlich irgendwo langen, wo man sie nicht haben möchte Das geht in der .gitignore Datei so:

*properties-hidden

Ich hoffe es ist dem ein oder anderen damit geholfen. Viel Spaß und Erfolg damit

Zudem legt man heutzutage seine Sourcen in einem Versionsverwaltungs-Tool ab (z.B. github oder bitbucket). Sofern es sich nicht unbedingt um ein privates Repository – auf einem eigenen Server – handelt, ist es immer sinnvoll solche Properties-Dateien aus der Versionsverwaltung auszuschließen (z.B. um das Ablegene von Passwörtern zu vermeiden).

Mit dem folgenden Code lassen sich simple Dateien (s.u.) in Scala auslesen und nutzen:

user.name=databaseuser
user.password=secure

import scala.io.Source

val filename = "database.properties"
for (line <- Source.fromFile(filename).getLines()) {
  println(line)
}

Wie ihr seht, nutzt man hierzu die Klasse scala.io.Source um die Datei zeilenweise in einer for Schleife auszulesen. In dem Beispiel gebe ich die Zeilen nur aus. hier wäre es natürlich denkbar, dass man mit dem Benutzernamen und dem Passwort einen Datenbankzugriff konfigurieren kann.

Ich wünsche viel Erfolg beim Ausprobieren !

Eine Äquivalenzklasse besteht aus einer Menge an Daten, welche als äquivalent angesehen werden, d.h. sie liefern erwartungsgemäß bei einem Test dieselben Ergebnisse. Jeder Datenwert innerhalb einer Äquivalenzklasse ist also so gut wie jeder andere. Die Datenwerte können dabei entweder aus tatsächlichen Wertebereichen, wie z.B. 0 bis 100, oder aus Mengen an Datensätzen bestehen. Für den Test bietet dies folgende Erkenntnisse (nachzulesen in A Practitioner’s Guide to Software Test Design – Copeland, L., 2003):

1. Falls ein Testfall einer Äquivalenzklasse einen Fehler aufdeckt, so decken auch alle anderen Testfälle der Äquivalenzklasse den Fehler auf.
2. Falls ein Testfall einer Äquivalenzklasse keinen Fehler aufdeckt, so decken auch alle anderen Testfälle der Äquivalenzklasse keine Fehler auf.

Interessant ist also die tatsächliche Wahl der äquivalenten Daten einer Äquivalenzklasse. Allgemein betrachtet ergeben sich zwei Möglichkeiten:

1. Verwendung von gültigen Wertebereichen (Testing-by-contract)
2. Verwendung von ungültigen Wertebereichen (Defensive testing)

Bei dem Testing-by-contract Ansatz geht man davon aus, dass der zu testende Softwareteil (auch Modul genannt) nur Eingabeparameter erhält, welche es verarbeiten kann. Zudem werden dem Modul unabhängig von der Eingabe Daten zur Verfügung gestellt, welche es zur fehlerfreien Verarbeitung der Eingabeparameter braucht. Entsprechend werden hierbei nur Äquivalenzklassen mit gültigem Wertebereich erstellt und durch ihre Repräsentanten getestet.

Äquivalenzklassen mit Daten außerhalb des zulässigen Bereichs werden hierbei nicht berücksichtigt, weil man evtl. davon ausgeht, dass die unzulässigen Bereiche nicht erreicht werden. Problematisch ist bei diesem Ansatz die Tatsache, dass Probleme auftreten könne, sobald ein unzulässiger Bereich in einem ausgelieferten Produkt tatsächlich erreicht wird (z.B. das Jahr 2000 bei einer 1985 geschriebenen Software). Um diesem Problem entgegenzuwirken, werden beim defensive-testing Ansatz auch unzulässige Bereiche zugelassen. Dies bedeutet, dass neben einer Äquivalenzklasse im gültigen Bereich auch mindestens eine Äquivalenzklasse für den ungültigen Bereich erstellt werden und durch einen Repräsentanten getestet werden muss. Die Anzahl nötiger Testfälle erhöht sich zwangsläufig.

Ein kleines Beispiel dazu:

Man hat ein Softwaremodul, das die Wurzelfunktion implementiert und nur ganze Zahlen im Bereich 0 bis 64 akzeptiert. Beim Testing-by-contract Ansatz benötigt man (grob betrachtet) zwei Äquivalenzklassen mit entsprechenden Repräsentanten. Eine davon nennen wir mal die Ganzzahl-Äquivalenzklasse und die andere Dezimal-Äquivalenzklasse. Wir gehen davon aus, dass die Ganzzahl-Äquivalenzklasse alle Eingabeparameter enthält, bei denen das Modul als Ergebnis eine Ganzzahl liefert, z.B. 4 oder 16. Hieraus wählen wir einen Repräsentanten, die 16, was dem ersten Testfall entspricht. Für die zweite Äquivalenzklasse nehmen wir entsprechend die 17, da hier bekannt ist, dass keine Ganzzahl als Ergebnis zu erwarten ist.

Beim defensive-testing werden nun weitere Äquivalenzklassen hinzugefügt. Wir erwarten z.B., dass das Modul bei der Eingabe einer negativen Zahl, einer Dezimalzahl oder einer Zahl größer 64 eine Fehlermeldung liefern muss. Mit der Bildung der entsprechenden Äquivalenzklassen (Negativ-Äquivalenzklasse, Dezimaleingabe-Äquivalenzklasse und Zugroßeeingabe-Äquivalenzklasse) erhält man drei weitere Testfälle: z.B. (-1|0,3|65) oder (-5|20,1|1200). Das erste Beispiel wird sicherlich öfter Anklang finden, da beim Testen versucht wird auch die Grenzbereiche (0/64) ausreichend zu testen.

Der Tester kann durch die Automatisierung einzelner Aktivitäten bei der Testfallermittlung geleitet werden. Des Weiteren bietet die Klassifikationsbaum-Methode eine Möglichkeit zur grafischen Notation, die eine Visualisierung der Testfallermittlung unter Verwendung moderner grafischer Oberflächen ermöglicht. Nachfolgend möchte ich die Methode zunächst allgemein beschreiben und danach zum besseren Verständnis an einem Beispiel verdeutlichen.

Die Ermittlung der Test relevanten Aspekte erfolgt meist manuell durch den Tester mittels der funktionalen Spezifikation des Testobjektes. Diese dienen der einfachen Unterscheidung der möglichen Eingabedaten. Im Anschluss wird die Menge aller möglichen Eingaben unter dem jeweiligen Aspekt disjunkt in Klassen zerlegt. Alle Werte einer Klasse sind demzufolge äquivalent (bei Interesse kann man sich zusätzlich meinen Beitrag zu Äquivalenzklassen durchlesen). Im konkreten Testfall reicht ein Repräsentant aus. Die Zerlegung unter den Aspekten sind Klassifikationen.

In komplexen Systemen werden Klassen mit Hilfe vo Klassifikationen wiederum in weitere Klassen unterteilt. Das rekursive Vorgehen resultiert in einem Klassifikationsbaum, der die anschauliche Darstellung der mehrstufigen Zerlegung repräsentiert. Klassifikationen werden in der grafischen Darstellung des Baumes als benannte Rechtecke dargestellt. Darunter werden jeweilige Klassen angeordnet. Entsprechend werden die tiefer liegenden Klassifikationen mit ihren Klassen jeweils unter der zugehörigen Klasse notiert.

Im letzten Schritt der Methode werden die Testfälle gebildet. Aus der Kombination verschiedener Klassifikationen entsteht jeweils ein Testfall. Dieser wird in Form einer Zeile in einer Kombinationstabelle notiert. Die Namen der Spalten dieser Tabelle resultieren aus den Blättern (Klassen) des Baumes. Bei logisch unvereinbaren Kombinationen (z.B. Klassen ein und derselben Klassifikation) bleibt der Tabelleneintrag leer.

Die Ermittlung der Test relevanten Aspekte ist oft vom Tester abhängig. Genauer kommt es hierbei auf Kreativität und Verständnis des Problembereichs an. Dadurch ergibt sich die Möglichkeit, dass Fehler im Testobjekt aufgrund unvollständiger Klassifikationsbäume unerkannt bleiben.

Die Methode soll am folgenden Beispiel veranschaulicht werden: Ausgangspunkt ist eine Spezifikation einer Computer-Vision-Systems, welches mit einer Kamera verschiedene Objekte erkennen soll. Mögliche Test relevante Aspekte können hierbei Farbe und Form sein. Damit ergeben sich die Klassifikationen für Farbe und Form. Die Klassifikation Farbe lässt sich beispielhaft in drei Klassen unterteilen: Rot, Gelb und Blau. Bei der Form könnte das Objekt exemplarisch in Kreis, Dreieck oder Rechteck unterteilt sein. Zur Repräsentation einer tiefer liegenden Klassifikation wird die Art eines Dreiecks betrachtet. Hierbei wird zwischen gleichseitigen, gleichschenkligen und ungleichseitigen Dreiecken unterschieden. Mit Hilfe des Klassifikationsbaums können nun Testfälle bestimmt werden.

Im ersten Schritt benötigen wir den Postgresql Server aus den Quellen:

sudo apt-get install postgresql

Je nach Version, die ihr haben wollt, geht das auch so (hier z.B für die 8.3):

sudo apt-get install postgresql-8.4

Im nächsten Schritt geht es nun schon an PostGIS:

sudo apt-get install postgresql-8.4-postgis

Da wir ja auch bequem per Webinterface Zugriff haben möchten, installieren wir nun auch den PHP-PG-Admin:

sudo apt-get install phppgadmin

Um auf den Admin zugreifen zu können, muss man noch ganz kurz den Apache restarten (wenn es nicht schon bei der Installation automatisch passiert):

sudo /etc/init.d/apache2 restart

Die Hauptarbeit ist nun getan. Allerdings fehlen uns noch die Zugangsdaten. Dazu wechselt man als root zum User postgres…

sudo su postgres

… und legt einen Superuser für die Datenbank an:

createuser -l -P superuser

Das “L, bzw -l” bedeutet, dass sich der User einloggen darf. Zudem soll der Zugang per Passwort geschützt sein (-P). Es folgt eine doppelte Passwortabfrage und die Frage, ob der User als Superuser angelegt werden soll. Ja, das soll er.

Das Grundsystem steht nun. Was uns noch fehlt, ist eine Datenbank mit der wir arbeiten möchten. Diese legen wir (am besten mit UTF-8 Encoding) mit diesem Befehl hier an:

createdb mydatabase --encoding="UTF-8"

Dieser Datenbank müssen wir noch den “Slang” (den Dialekt) von Postgis beibringen:

createlang plpgsql mydatabase

Danach müsste alles erledigt sein. Ihr könnt euch nun im Web-Admin anmelden, neue User anlegen und mit der Datenbank arbeiten. Ich wünsche viel Spaß und Erfolg