Ich wollte eine Möglichkeit finden, ein Git-Repository auf Bitbucket.org direkt mit unserem Webserver zu synchronisieren. Es sollte also beim “git push” (dem Veröffentlichen der lokal durchgeführten Änderungen im Projekt im Bitbucket.org Konto) ebenfalls die Webseite aktualisiert werden.

Zurück an den Anfang: Das Webprojekt

Grundsätzlich war es das Ziel, eine Lösung für einfache und sichere Zusammenarbeit an einem gemeinsamen Webprojekt zu ermöglichen. Das Webprojekt war in unserem Fall eine Laravel 5 (PHP-Framework) Applikation, an der von zwei Personen regelmäßig gearbeitet werden sollte.

Wir hatten für das Projekt lediglich den Live-Server zur Verfügung. Da wir beide auch so gut wie nie am gleichen Ort beim Entwickeln waren, kam eine direkte Bearbeitung der Dateien am Server so nicht in Frage. Wobei das ist eigentlich grundsätzlich keine gute Idee!

Warum Git?

Beim gemeinsamen Arbeiten an einem Projekt ist gleich zu Beginn die Frage nach geeigneten Kollaborations-Tools aufgetreten.

Ich habe dabei sofort an Git denken müssen. Schließlich bietet die Versionierung mittels Git vielfältige Vorteile beim Arbeiten im Team. Für uns am wichtigsten waren wohl folgende:

• Git ist optimal für Teamarbeiten bei Software- und Webprojekten.
• Es gibt sehr gute Client-Software (zB. SourceTree), welche für Windows und Mac OS X gratis verfügbar ist.
• Es gibt Anbieter, die Gratis Git-Repositories anbieten (in unserem Fall: Bitbucket.org).

Bitbucket

Also wurde zu Beginn der Zusammenarbeit  die Versionierung mittels Git anhand eines Repository bei Bitbucket.org angelegt. So weit so gut!

Jetzt sind zwar die Quellcodes mittels Git versioniert, nur könnte jetzt natürlich jederzeit beim kopieren auf den Server Änderungen vom Kollegen überschrieben werden. Und wenn es nicht gleich auffällt, dann muss erst recht nach dem Fehler gesucht werden.

Also habe ich mir überlegt, wie man diese Fehlerquelle, die das Zusammenarbeiten in unserem Fall auch relativ unpraktisch gemacht hat, eliminieren kann.

Bei Bitbucket sah ich dann, dass es die Möglichkeit gibt, verschiedene Aktion automatisch bei bestimmten Auslösern auszuführen.

Der POST-Hook

Mittels des POST-Hooks kann eine Service-URL angegeben werden. Dieser wird dann direkt nach einer Änderung im Repository angestoßen.

Wie kann der POST-Hook eingerichtet werden

1. Go to the repository’s  settings.
2. Click Services in the left-hand navigation.
   The Services page appears.
3. Select the POST service from the services dropdown.
4. Click Add service.
   A new section appears for the POST service.
5. Enter the URL where Bitbucket should send its update messages.
6. Press Save.

Zur URL, die eingegeben werden muss, kommen wir am Ende …

Wie aktualisieren wir jetzt aber die Webseite?

Glücklicher Weise gibt es unter folgendem Link ein kleines PHP-Paket, das mittels minimaler Anpassung an der config.php genau das für uns macht.

https://bitbucket.org/alixandru/bitbucket-sync

Die wichtigsten Schritte hier nochmals kurz zusammen gefasst:

• Die Quellcodes von https://bitbucket.org/alixandru/bitbucket-sync herunterladen.
• Die entpackten Quellen (1 Ordner /bitbucket-synch/) genau so samt des Ordners direkt ins Hauptverzeichnis am Webserver, der synchronisiert werden soll, laden.
• config.php.example in config.php umbenennen und nach den eigenen Bedürfnissen anpassen. Weitere Schritte erst nach der Einrichtung der config.php durchführen!!!
• Schreibberechtigungen entsprechend der Anleitung in der config.php setzen. Der Ordner “commits” ist dabei jedenfalls der wichtigste, denn dort werden die temporären Commits von Bitbucket geladen. Test, in dem “gateway.php” mit dem Parameter “test” im Browser aufgerufen wird (You can test if this folder is writable by accessing the gateway.php script with test parameter in your browser (e.g., http://mysite.ext/bitbucket-sync/gateway.php?test)
• Das Projekt muss einmal initial importiert werden. Dazu muss im Browser die URL der Webseite samt folgendem Teil aufgerufen werden: deploy.php?setup=my-project-name
• Wer bis hier her kommt, kann mit dem Pushen der Änderungen beginnen. Die Webseite sollte mit minimaler Verzögerung am aktuellen Stand sein.

Bitbucket-Sync lädt nun nach jedem “git push” automatisch eine ZIP-Datei vom Bitbucket Repository in den “commits” Ordner. Diese wird dann entpackt und in das eingestellte Verzeichnis geladen.

Die Webseite kann somit mit geringem Einrichtungsaufwand automatisch nach einem GIT Push (Veröffentlichen der Änderungen) aktualisiert werden!

Exkurs POST-Hook URL

• Bitbucket-Sync benötigt Lesezugriff auf das Repository. Falls Ihr ein privates Repository habt, müsst ihr einen Benutzer mit Leserechten in den Einstellungen anlegen.
• Es empfiehlt sich außerdem eine Authorisation Key als GET-Parameter in folgender Form zu übergeben:
  http://www.deine-url.at/bitbucket-sync/gateway.php?key=predefined-gw-key

FAZIT: Das Einrichten von “bitbucket-sync” dauerte sicher auch nicht länger, als diesen Beitrag zu verfassen. Und es läuft problemlos

Quellen:

• https://de.atlassian.com/software/sourcetree/overview
• https://www.sourcetreeapp.com/
• https://de.atlassian.com/software/bitbucket/overview
• https://bitbucket.org/
• https://bitbucket.org/alixandru/bitbucket-sync
• https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html

The post Bitbucket Synchronisierung appeared first on Mobile USTP MKL.

 Vorkenntnisse für unsere ReST-API

(ReST = Representational State Transfer)

Ein ReST-Webservice stellt verschiedene Methoden über HTTP Parameter zu Verfügung.

Die Methoden

Das Interface von ReST ist generisch. Es müssen keine Protokoll-Konventionen bekannt sein, damit Client und Server sich verständigen können. Die folgende Aufzählung beschreibt die Bedeutung der HTTP-Methoden, wie sie von ReST verwendet werden.

• GET: GET fragt die Repräsentation einer Resource ab. Requests sollten frei von Seiteneffekten sein. GET Requests können beliebig oft abgeschickt werden.
• POST: Mit POST kann einer Resource etwas hinzugefügt werden. Beispielsweise könnte eine Ware zu einem Warenkorb hinzugefügt werden. POST ist nicht frei von Seiteneffekten. Beispielsweise können durch einen POST Aufruf Felder in einer Datenbank verändert oder Prozesse auf dem Server gestartet werden.
• PUT: Neue Resourcen können mit PUT erzeugt, oder der Inhalt bestehender Resourcen kann mit PUT ersetzt werden.
• DELETE: Resourcen können mit DELETE gelöscht werden.

Zudem können noch verschiedene Datenformate für die Kommunikation verwendet werden:

• JSON (JavaScript Object Notation)
  JSON wird zur Übertragung und zum Speichern von strukturierten Daten eingesetzt; es dient als Datenformat bei der Serialisierung. Insbesondere bei Webanwendungen und mobilen Apps wird es in Verbindung mit JavaScript, Ajax oder WebSockets zum Transfer von Daten zwischen dem Client und dem Server häufig genutzt.
• JSON-P (JavaScript Object Notation mit Padding)
  JSONP (JSON mit Padding) ermöglicht die Übertragung von (JSON-)Daten über Domaingrenzen, ist jedoch mit Sicherheitsrisiken behaftet.
• XML (Extensible Markup Language)
  XML ist eine Auszeichnungssprache und somit vielseitiger einsetzbar als JSON, das ein Datenaustauschformat ist. XML ist weiter verbreitet, wird jedoch von JSON aufgrund seiner Einfachheit dort zurückgedrängt, wo keine komplizierten Auszeichnungen notwendig sind.

Wir benötigen in diesem Fall JSON-P.

Was muss gemacht werden

Grundsätzlich muss eine Anfrage samt aller Parameter entgegen genommen und nach abarbeiten des Scripts ein Antwort zurückgeschickt werden.

Zuerst werden die übergebenen Daten überprüft. In diesem Fall wird beim Aufruf der URL der Parameter “ean” erwartet.

if (isset($_GET["ean"])) {

 $ean = $_GET["ean"];

 // Hier wird dann die Logik ausgeführt (z.B. Daten aus der DB mittels "ean" holen)
 // Wichtig ist nur, dass am Ende ein valides Javascript Object übergeben wird. 
 // Dies erreichen wir, in dem die Rückgabe zuerst in einem Array gespeichert wird.

$response_array = {'id' => 1, 'title' => 'Mein Titel'};
}

Am Ende wird dieses Array dann mittels “json_encode($response_array)” als JSON ausgegeben. Falls ein JSON-P Rückgabe notwendig ist, muss das JSON mittels des “Callback” Werts aus der Anfrage übergeben werden.

//start output
$callback = $_REQUEST['callback'];

if ($callback) {
    //JSON-P
    header('Content-Type: text/javascript');
    echo $callback . '(' . json_encode($response_array) . ');';
} else {
    //JSON
    header('Content-Type: application/x-json');
    echo json_encode($response_array);
}

Entscheidend ist, dass die Daten mittels

 json_encode(.....)

übergeben werden!

POSTMAN: Hilfreich um ReST-API’s zu testen

Rückgabe der API testen

Um die API zu testen, gibt es ein paar hilfreiche Tools wie zum Beispiel die Chrome Extension Postman, mit deren Hilfe das Testen etwas einfacher und schneller geht. Natürlich kann man aber auch problemlos über die Console mittels “curl” testen.

Wenn alles funktioniert, dann bekommt man als Belohnung für den Aufwand die Daten analog zu meinem Beispiel hier zurückgeliefert.

{
"getParams": {
"ean": "9009457092232"
},
"products": {
"58766": {
"uid": "58766",
"name": "Breitverteilerdüse 4,5,6",
"artnr": "52816",
"ean": "9009457092232",
"lagerplatz1": "86.1.6",
"lagerplatz2": "21.27.2",
"new": "0",
"top": "0",
"short": "",
"description": "58766",
"fotos": "52816_bild.jpg,52816_skizze.jpg",
"documents": null,
"category": "49947",
"category_title": "Breitverteiler Düse",
"category_parent": "49921",
"productunit_description": "pro Stück",
"taxrate_percent": "20",
"price_onrequest": "0",
"price": "57.50",
"currency": "1",
"currency_symbol": "€",
"priceWithTax": 69,
"category_breadcrumbs": "Kategorie: > Hauptkategorien > Gülle > passend zu System Bauer > Breitverteiler Düse",
"foto": "http://www.geheimeurl.com/uploads/tx_itcshop/52816_bild.jpg",
"skizze": "http://www.geheimeurl.com/uploads/tx_itcshop/52816_skizze.jpg"
}

Quellen:

• https://de.wikipedia.org/wiki/JavaScript_Object_Notation#JSONP
• http://www.oio.de/public/xml/rest-webservices.htm

UPDATE

Im Nachhinein würde ich sagen, dass es wohl etwas geschickter wäre, direkt TYPO3 zu bemühen, um die Daten auszuliefern. Dadurch gibt es dann auch Zugriff auf die Funktionen der Extbase-Erweiterung mit den Produkten. Es wäre dann bei Änderungen nicht nötig, die Funktionalität der API an die der Extension anzupassen, zumindest solange sich nur Hilfsfunktionen (wie Preisberechnung oder Versandkostenberechnung) ändern.

Dadurch, dass ich das jetzt händisch, ohne auf TYPO3 zurückzugreifen, erledigt habe, mussten natürlich sämtliche Ausnahmen und Berechnung nachgebaut werden.

Damit das beim nächsten Mal besser gelöst wird (oder falls es hier jemand liest und gleich richtig angehen möchte), stelle ich hier Links zu einer besseren Lösung bereit. Für TYPO3-Entwickler sei hier erwähnt, dass dafür “Extbase PHP based View” genutzt wird:

Quellen:

• https://docs.typo3.org/typo3cms/ExtbaseFluidBook/latest/8-Fluid/9-using-php-based-views.html
• http://wiki.t3easy.de/extbase-und-fluid/extbase-php-based-view/

The post Webservice für TYPO3-Datenzugriff appeared first on Mobile USTP MKL.

Was ist Gradle?

Gradle ist ein Tool zur Build-Automatisierung und zum Build-Management. Es dient der Automatsierng von Builds, Tests, Publishing Deployment. Gradle nutzt dazu eine auf Groovy basierte domainspezifische Sprache (DSL)

Welche Ziele werden mit Gradle verfolgt?

• Einfache Wiederverwendbarkeit von Code und Ressourcen
• Unterstützung von mehreren Build-Varianten einer Applikation
• Konfigurieren, erweitern und anpassen des Build-Prozesses
• Gute IDE-Integration

Build-Dateien

Gradle nutzt für einen einfachen Build hauptsächlich drei Dateien:

• build.gradle – die auf der Gradle-DSL beruhende Definition des Builds mit allen Tasks und Abhängigkeiten eines Projekts (ein Multiprojekt hat pro Projekt eine solche Build-Datei, die durch Vererbung der Eigenschaften von ihrem „Vater“-Buildskript kurz gehalten werden können).
• settings.gradle (optional) – bei einem Multiprojekt werden hier die teilnehmenden Unterprojekte festgelegt.
• gradle.properties (optional) – eine Liste von Properties, die für die projektspezifische Gradle-Initialisierung eines Builds gültig sind.

Gradle-Skripte können unmittelbar Groovy-Code enthalten oder durch eine Groovy-Klasse implementiert werden. Alternativ lassen sie sich als Build-Abhängigkeit aus einem Maven-Repository laden

Build-Konfiguration

Die Build-Konfiguration wird in den Gradle Build-Dateien mit der Syntax und den Optionen von Gradle und dem Android Gradle Plugin definiert. Folgende Aspekte sind konfigurierbar:

• Build variants. Es können mehrerer APKs mit unterschiedlicher Konfiguration aus einem Projekt erzeugt werden
• Dependencies. Die Abhängigkeiten werden von Gradle gehandhabt. Es unterstützt Projektabhängigkeiten, lokale Ahängigkeiten als auch Remote repositiories (z.B.: Maven, Ivy)
• Manifest entries.  Bestimmte Werte der Manifest-Datei können hiermit überschrieben werden (z.B.: “package name”, “minimum SDK version” und “target SDK verison”)
• Signing. Die erzeugten APK’s können automatisch signiert werden
• ProGuard. Dient dem automatischen verschleiern des Quellcodes (= Obfuscator)
• Testing. Es wird eine eigene Test-APK von den Test-Quelldateien im Projekt erzeugt. Die Tests können während des Build-Prozesses ausgeführt werden
• NEU: APK split. Splits verfeinern die Möglichkeiten der “Build variants” bei Multi-APKs. Es gibt folgende Splits: Density split, ABI split.

Gradle Wrapper

Der Gradle Wrapper ermöglicht es Gradle ohne lokale Installation zu nutzen. Stattdessen wird die entsprechende Version von Gradle beim ersten Build des Projekts heruntergeladen. Dadurch ist es auf einfache Art und Weise möglich unterschiedliche Gradle Versionen für unterschiedliche Projekte zu nutzen.

Der Gradle Wrapper besteht aus einer Batch-Datei für Windows, eines Shell-Skript für andere Betriebssysteme, einer JAR-Datei und einer Properties-Datei.

Musterbeispiel: “build.gradle”

apply plugin: 'com.android.application'

android {
 compileSdkVersion 20
 buildToolsVersion "20.0.0"

 defaultConfig {
  applicationId "at.itcenter.demoapp"
  minSdkVersion 15
  targetSdkVersion 20
  versionCode 1
  versionName "1.0"
 }
 signingConfigs {
  release {
   storeFile file("myreleasekey.keystore")
   storePassword "password"
   keyAlias "MyReleaseKey"
   keyPassword "password"
  }
 }
 buildTypes {
  release {
   runProguard true
   proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
   signingConfig signingConfigs.release
  }
 }
}

dependencies {
 compile fileTree(dir: 'libs', include: ['*.jar'])
 compile 'com.android.support:support-v4:20.0.0'
}

Quellen:

http://developer.android.com/sdk/installing/studio-build.html
http://tools.android.com/tech-docs/new-build-system/user-guide
http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
http://www.gradleware.com/android/gradle-the-new-android-build-system/
http://www.gradle.org/docs/current/userguide/userguide_single.html
http://www.gradle.org/docs/current/dsl/index.html
http://de.wikipedia.org/wiki/Gradle

The post Gradle: Build-Automatisierung mit Android Studio appeared first on Mobile USTP MKL.