iOS swift framework

iOS – Developing reusable Views in a Swift Framework

What does „Framework“ mean in iOS?

Usually a Framework is a code library, which defines a structure and offers functions to easily solve complex software and coding issues.
Regarding the iOS development the term „framework“ is a little more universal. An iOS Framework can consist of only a single class or be a complex semi application, which just has to be included and configured to produce a launchable app. Basically it is nothing more then a collection of views, controllers and other classes/files that can be shared along an infinite number of projects.

What do we want to achieve?

In this post, I will create an iOS Framework and include it in a test app project. Doing that, I will focus on the reusability of single components of the Framework.

In short, this post includes:

  • Creating a Framework for iOS-Projects with Swift
  • Including the Framework in an app project
  • Creating a resuable, configurable and extendable View that is connected to Class which defines most of its logic
    • + using that view in our test app project
  • Creating reusable classes
    • + Using those classes in our test app project

To achieve all that, I am going to create a simple Framework, containing a basic login View with a View Class, which will define the behavior of the View and offer some attributes for the possibility to configure the appearance of the View. Afterwards, I will include the Framework in a test app.

So let’s get started

Creating the Framework project is quite simple (Xcode Version 7.2.1): In Xcode, go to File -> New -> Project. Now the templates dialog should be visible.
On the left, choose -> Framework & Library, then click on Cocoa Touch Framework and confirm by clicking „Next“

create ios framework

In the following steps, you define the core data of your project as usual. Make sure you have „Swift“ selected as the project’s language.

Creating the View

So after creating the project, we can directly go to creating our first view. Our primary goal is to make this one reusable, i.e. you should be able to switch the View classes and/or Controller classes at any time.

To achieve that, we do not create that view in our Storyboard but in a seperate .xib file.

To do that, right click on your project folder and choose „New File…“

create iOS file

On the left, choose iOS -> User Interface, click „View“ and then „next“

create iOS view

I named the view „MyLoginView“. When you select it in the navigator, you can define the View the same way, you would do it in the Storyboard.

I just went ahead and created a simple login View, containing fields for username and password, a label to display error messages and a login button.

iOS standalone View

If you have never created a View before, you can learn how to do that in the iOS Documentation

Bringing the View to life

So now that we have the View, we have to take care of defining the behavior of the View. To do that, we will create a View Class, which will take care of loading the .xib file and define the behavior of its elements.

So again, click on your project folder in Xcode and select „New File…“. In the dialog, choose iOS -> Source -> Cocoa Touch Class

create iOS Class define iOS Class

To keep things structured, I gave the file the same name as its view „MyLoginView“
For „Subclass of“ choose „UIView“
and make sure the selected language is „Swift“

Now comes the tricky part. We have to make sure that the View gets properly loaded when this class is used on a Storyboard or as subview. Right now it is not possible to simply attach a file to a view so that it gets automatically assigned when dragged into the storyboard. So we need a little setup code.

I will put all the setup code in a seperate method called „setup()“. This will include the following actions (if you don’t want to know the exact behavior, you can scroll down a little and copy the setup() entirely) :

First of all, define two variables

let nibName:String = „MyLoginView“
var view: UIView!

Now, we have to load our login View and add it as subview to make it visible.

Loading the View can be done by the following one-liner:

self.view = UINib(nibName: self.nibName, bundle: NSBundle(forClass:
self.dynamicType)).instantiateWithOwner(self, options: nil)[0]
as! UIView

This line includes three actions:

  • Loading the current project bundle by creating an instance of NSBundle()
  • Loading the View file by creating an instance of UINib()
  • Creating a UIView instance of our View file with instantiateWithOwner()

The result will be assigned to our view variable, that we declared earlier.

So now that we have loaded the View file, we have to add it as subview and make sure it is properly displayed.
We do that by executing:

self.view.frame = bounds
self.view.autoresizingMask = [.FlexibleWidth, .FlexibleHeight]


So our setup method looks like this:

func setup() {
self.view = UINib(nibName: self.nibName, bundle:
options: nil)[0] as! UIView
self.view.frame = bounds
self.view.autoresizingMask = [.FlexibleWidth, .FlexibleHeight]

The final step is to call that function from the initializer. The UIView class has two initializers that are of our interest. One is for displaying the View inside the editor and the other one is the important one that allows us to show the view inside the real app.

I will use both:

public override init(frame: CGRect) {
super.init(frame: frame)
public required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)

So that’s it, basic work is done. It is a good idea to put that part in a Base Class and let your actual views extend that class so you don’t have to copy that code to every View you create.

Now we want to get some actual logic inside that view.
To recall, we wanted to create a simple Login view and a Class that handles most of the basic work.
So to be able to do anything, we have to get references to the elements inside the view.
The first step to doing that, is setting our View Class as the .xib file’s owner

Select the MyLoginView.xib in the Navigator and then select „File’s Owner“ in the Editor area. Now select the Identity inspector tab in the utilities area and type „MyLoginView“ as Class in the Custom Class area.



This allows us to control-drag elements from the View into our View class, so we’re going to do that.
Simply hold the Ctrl key and drag any element to the class, using the assistant editor.

control drag view element define-element-variable

Go ahead and do that with every element you want to control inside the Class. I’m going to do it with the text fields and the error label.
Additionally I will add an action for the click event that will trigger the actual login.

control drag button define button action



The purpose of a Framework is to implement most of the required logics so that you don’t have to repeat the code in the actual project, but of course there are always parts that can not be implemented in a Framework. In our case the login is one of those examples. Each app might have a different server or a different method of authenticating so we have to leave the actual login to the app itself.
How you abstract your code is totally up to you. One possibility is the use of @IBInspectable, which allows you to define properties in your View class that can be directly set in the attributes inspector of the editor.

In our case, I am just going to define a public closure attribute, which is a function that will be called as soon as the user hits the login button. So by setting that attribute in the actual app, the developer is able to implement the login process.

So in my MyLoginView class, I will add a public property

public var loginHandler:((username: String, password: String)
-> Void)?

and add the call of that function to the login action

@IBAction func login(sender: UIButton) {

if(loginHandler == nil) {
print(„No loginHandler defined“)

username: usernameTextfield.text!,
password: passwordTextfield.text!)

Using the Framework in an app project

For now, we have a solid Framework for a login view and of course we want to use it in an actual app.
To do that, we first have to build the Framework to create an embeddable .framework file. If you expand the „Products“ group
in the Project navigator on the left, you will see that MyFramework.framework is red. That means that it has not yet been built.
To do that, first set the active scheme to „Generic iOS device“ by selecting it in the scheme selector at the top of Xcode.


iOS scheme selector

Now press Cmd + B (or Product -> Build in the menu bar)

After a little bit of building, the MyFramework.framework file should appear black, so we are ready to embed it in an actual project.

Right click on the MyFramework.framework file und select „Show in Finder“.
If you step back one folder, you will see that XCode has created two build folders: Debug-iphoneos and Debug-iphonesimulator

As you may have already suggested, the first folder contains the build result for iPhone devices and the other one is for the simulator.

For simplicity, we are just going to embed the debug build for the simulator.

First we have to create our iOS project. I will name mine „MyFrameworkTest“ and use the single view application template to create it.

There are many ways to get a Framework file embedded in an iOS project, but in our case we have to make sure that the binaries are linked and embedded in our test project.
To tell Xcode to do that all at once, click on the Root node in the Project navigator (MyFrameworkTest), select the one Target under „Targets“ and select the „General“ tab.
Now scroll down to „Embedded libraries“ and click on the plus icon.

add embedded binaries

In the dialog, click „Add other“ and navigate to your .framework file

iOS choose framework

In the options dialog, leave everything as it is and click on „Finish“

Using the Framework

Now we want to use the login View, we created in the framework project.
Go to the Main.storyboard and expand the View Controller Scene and the View Controller. This should have one View and we can use that directly as
our login View.

Select that View and select the Identity Inspector tab in the utilities area on the right. In the Custom Class area type „MyLoginView“ (Xcode should autocomplete it) and type „MyFramework“ as module

iOS embed framework View

Congratulations! You just embedded your first logic containing Framework View in your own app.
But there is one thing left to do: Define the actual behavior for the login button click.

For that, i created the public loginHandler attribute in the MyLoginView class. The only thing
we have to do is initialize it with a function in our app.

First, we are going to need a Controller for this view. When you just created the app, Xcode automatically creates a ViewController. If you don’t have it or don’t want to use it you can just create another one by creating a Cocoa Touch Class and letting it extend UIViewController.

In both cases you have to make sure the controller is assigned in your Main.storyboard

iOS assign controller

Now go to the View Controller and control-drag our login View into the controller.


Now we have the instance of our login View in the controller. You will notice that MyLoginView is underlined and Xcode is telling us that it can’t find that class.
That is because we didn’t include it yet in the View Controller. To do that, just add the following line above the class:

import MyFramework

Now we can define the login function in our View Controller:

func login(username: String, password: String) {
let alert = UIAlertController(title: „Login“, message:“I guess i should log in now“, preferredStyle: .Alert)
alert.addAction(UIAlertAction(title: „OK“, style: .Default) { _ in })

self.presentViewController(alert, animated: true){}

and assign it as the login handler in the viewDidLoad function

override func viewDidLoad() {

loginView.loginHandler = self.login

And that’s it! We can go right ahead and run the app.
When clicking the login button, it should show the alert dialog.

iOS app result

You can checkout the projects from our git repository

Framework project

Test project

Android Best Practices with RoboGuice Best

Android Best Practice mit RoboGuice & Otto

Um der schier unendlich steigenden Nachfrage nach mobilen Applikationen hinterher zu kommen, ist das Wissen um Android Best Practices bei der Entwicklung von Handy Applikationen von wesentlichem Vorteil.

Im folgenden wollen wir aufzeigen, worauf bei der Entwicklung mit Android zu achten ist, welche Fallstricke man geschickt umgehen kann und wie man mit RoboGuice Boilerplate Code vermeiden kann. Zusätzlich wollen wir innerhalb unserer Best Practices zeigen, wie man mit Otto auf einfache Art und Weise einen Event-Bus einrichten kann, der eine saubere Trennung zwischen View und Businesslogik erlaubt. Hierdurch wird nicht nur die Geschwindigkeit der Applikation für den Nutzer sichtbar gesteigert.

Android Best Practice Grundgedanken

Das Aufsetzen eines neuen Projektes in IDEA IntelliJ ist denkbar einfach. Nutzt man das integrierte Template von IntelliJ kann man sofort auf Gradle-Basis loslegen. Doch leider haben wir bereits zu oft Projekte solcher Art gesehen. Aufgesetzt aus der IDE, ohne das Wissen von Best Practices losgelegt und den Quellcode, wie ein Geschwür, wuchern lassen. Das Resultat sind nicht nur Projekte die eine lange Einarbeitungszeit bedürfen sondern auch schlicht weg unwartbar sind. Technische Schulden wird dies heutzutage auch gerne genannt. Ausreden, die diese Schulden auf ein komplexes Produkt schieben werden nebenbei bemerkt auch gerne vorgeschoben. Dies ist aber nicht akzeptabel.

Dabei ist es so einfach mit ein paar Grundkenntnissen, auch ohne tiefergehendes Wissen um Android, sehr gut strukturierte und wartbare Projekte zu bauen.

Android Boilerplate Best Practices

Boilerplate ist die Bezeichnung für Quellcode, der immer wiederholt werden muss. Denken wir nur an Getter und Setter oder andere typische Muster aus verschiedenen Bibliotheken.

Um diesen Boilerplate-Code zu umgehen gibt es bereits einige gute Bibliotheken. Wir bevorzugen vor allem Dagger und RoboGuice. Zweiteres haben wir in unserem Beispiel oder Template Projekt – auf das wir am Ende des Artikels verweisen – eingebaut.
RoboGuice hilft typischen Android-Boilerplate zu verhindern. Vor allem bei dem referenzieren von UI-Elementen ensteht schnell Code, der sich immer wieder wiederholt. Im folgenden ein Beispiel für typische UI Referenzierung:

public class ExampleActivity extends Activity {

private Button myButton;

protected void onCreate(Bundle savedInstanceState) {
// …
myButton = (Button) findViewById(;
myButton.setText( „Hello, “ + myName );
// …

Durch RoboGuice können UI-Elemente weitaus eleganter und lesbarer injeziert werden:

public class ExampleActivity extends RoboActivity {

private Button myButton;

public void onCreate(Bundle savedInstanceState) {
// …
myButton.setText( „Hello, “ + myName );
// …

Natürlich lässt sich der Vorteil in diesem kurzen Beispiel nur erahnen, dennoch sieht es jetzt schon weitaus sauberer aus (kein Cast) und wird durch geschickte Vererbung noch praktikabler.

Das gleiche lässt sich mit RoboGuice durch die integrierte Dependency Injection (DI) erreichen. Das zugrunde liegende System ist dem von Spring aus der Java-Welt sehr ähnlich und funktioniert per Reflection. Ein gutes Beispiel kann hier gefunden werden:

Best Practice mit Hilfe des Event-Bus von Otto

Trotzdem die Entwicklung von mobilen Applikationen noch recht jung ist, können Best Practices aus der Desktop- und/oder Webentwicklung zu Grunde gelegt werden. So auch die Trennung zwischen dem View und der Logik. Ist keine Logik im View enthalten, kann dieser schneller und einfacher verändert oder gar ausgetauscht werden. So ist es auch in der Android-Entwicklung. Damit man jedoch zusätzlich das mobile Gerät bei teuren Interaktionen durch den Nutzer nicht blockiert, bietet sich ein Event-Bus an. Interaktionen können an die Logik übergeben werden und Listener eingerichtet werden, die darauf lauschen, wenn die Logik mit ergebnissen zurück kehrt. Das Ergebnis – gerade bei Android – ist eine weiterhin funktionierende und flüssige Anwendung. Diese wird nicht durch die Berechnung der Logik blockiert. Ganz im Gegenteil, die Berechnung wird durch einen weiteren Prozess des Handys, im Hntergrund, ausgeführt.

Unter folgender URL wird anschaulich erläutert, wie der Event-Bus eingerichtet und Listener registriert werden.

Das Best Practice Template

Wir haben basierend auf den genannten Punkten ein Best Practice Template für die Entwicklung von Android Applikationen angelegt. In unserem Github Repository unter folgender URL, könnt ihr dieses finden und gerne auch erweitern:

Wir wünschen euch damit viel Spaß.


Saltstack und Vagrant – ein perfektes Duo!

Jeder der sich schon einmal mit dem Thema Konfigurationsmanagement Servern auseinander gesetzt hat, wird die Begriffe Chef oder Puppet gehört haben. Diese Tools helfen deskriptiv die Installationsroutinen zu beschreiben und fortan auf jeglicher Umgebung auszuführen sind. Logisch nur, dass dies ein fundamentaler Schritt im Cloud-Zeitalter ist. Hilf das Konfigurationsmanagement doch virtuelle Server automatisiert aufzusetzen. Damit steht der automatisierten Skalierung nichts mehr im Wege.



Seit einiger Zeit tummeln sich einige neue Player, rund um das Konfigurationsmanagement oder auch die Orchestrierung, am Markt. Ein neuer Stern an diesem Himmel heisst SaltStack. Als einst beliebtestes GitHub Repository eroberte es schnell die Herzen der Administratoren und DevOps. Dabei setzt Saltstack anders als Chef und Puppet auf eine noch ausdrucksstärkere Sprache. Mit Hilfe von sogenannten SLS Dateien (Salt State) die im YAML-Format sind, werden so die Installationsroutinen beschrieben. Dies ist nicht nur sehr leserlich, es fühlt sich zu dem auch sehr leichtgewichtig an. Ebenfalls arbeitet SaltStack nach dem Client-Server-Modell. Es ist darauf ausgelegt für kleinere Netzwerk-Umgebungen genauso gut zu funktionieren, wie für unendlich große Server-Infrastrukturen. Dabei werden vom Master die Minions über so genannte Grains angesprochen. Dies sind beliebige Filter um die Menge der Clients einzugrenzen.

Installationsanleitungen und weitere Informationen findet ihr hier:



Vagrant ist eine in Ruby verfasste Anwendung, um virtuelle Maschinen zu verwalten. Besonders im lokalen Betrieb von virtuellen Maschinen bietet sich Vagrant an. Es hilft dabei einfach und schnell virtuelle Maschinen, mit verschiedensten Images, zu laden, zu starten, zu stoppen und auch wieder zu löschen. Noch besser, man kann deskriptiv beschreiben, welches Image genutzt werden soll, wie Verbindungen (Beispielweise Freigaben) zum eigenen Host-System aussehen sollen oder welche Ports über welche Netzwerkschnittstelle durchgeleitet werden sollen. Im Zusammenhang mit einer Versionsverwaltung für Quellcode ergibt das erstaunliche Möglichkeiten und vor allem eine gleiche Umgebung für alle Entwickler.

Installationsanleitungen und weitere Informationen findet ihr hier: Denkt auch daran, dass ihr idealerweise Virtualbox installiert habt (

SaltStack & Vagrant

Warum erläutere ich das eigentlich alles? Ganz einfach, wenn man Server automatisiert Konfigurieren möchte, muss man zunächst in einer Umgebung, die möglichst wieder herstellbar ist, diese Konfiguration testen.
Nun kann man natürlich den eigenen alten Computer nehmen, ein Linux darauf installieren und die ersten programmierten Zeilen in einer Konfigurationsmanagement-Technologie ausrollen und schauen was passiert. Funktioniert nicht alles auf Anhieb, wie man es erwartet hatte, wird man spätestens nach der 3 Installation von Linux, auf dem alten Computer, zum Strick greifen.
Es ist also nachvollziehbar, dass man ausschau hält,nach einer Technologie mit der man schnell und einfach eine frische Installation von Linux erhält. Genau das bietet Vagrant. Dazu braucht es nicht einmal einen alten Computer. Auf dem eigenen laufenden Computer kann eine virtuelle Maschine gestartet werden.

Damit jedoch, noch einfacher und automatisch, die geschrieben SaltStack-Zeilen ausgerollt werden, bedarf es noch einiger Konfigurationen. Die folgenden Zeilen versuchen demnach zu erläutern, wie man Vagrant zusammen mit SaltStack einsetzen kann, um die eine Serverkonfiguration zu schreiben und zu testen.

Den Quellcode, in Form eines Beispielprojektes, findet ihr wie immer auf GitHub: SaltStack Vagrant Beispiel


Am besten man startet mit einem neu angelegten Verzeichnis. Als Beispiel nennen wir es „SaltStack-Vagrant“. Darin legen wir eine Datei mit dem Namen Vagrantfile an. Der Inhalt könnte wie folgt aussehen:

# Vagrant file for use with SaltStack
Vagrant.configure(„2“) do |config|
## Choose your base box = „ubuntu/trusty64“
config.vm.synced_folder „saltstack/“, „/srv“
## Use all the defaults:
config.vm.provision :salt do |salt|
# call state.highstate in local mode
salt.masterless = true
# most important in this file is the option file_client: local
salt.minion_config = „etc/unicorn“
# execute highstate on start
salt.run_highstate = false
# install stable SaltStack
salt.install_type = „stable“
# default option when running boostrap script
salt.bootstrap_options = „-P -c /tmp“
# enable port forward for host system „forwarded_port“, guest: 5432, host: 5444

Durch diese Maßnahme teilen wir Vagrant mit, wie wir uns unser Image vorstellen, welche Schnittstellen es nach außen haben soll und das wir es gerne mit SaltStack initialisiert haben wollen.
Habt ihr Virtualbox und Vagrant auf eurem System installiert, könnt ihr dieses Setup testen indem ihr in das Verzeichnis „SaltStack-Vagrant“ wechselt und folgenden Befehl eingebt:

 $ vagrant up

Im folgenden wird Vagrant zunächst das Image beziehen, falls noch nicht geschehen und starten. Daraufhin werden die Ports und weiteres initialisiert und SaltStack ausgeführt.

Beispiel am GitHub-Repository

Am einfachsten und komplett ist das Beispiel bei GitHub ( Klont dieses mit folgendem Befehl (Git sollte installiert sein).

 $ git clone

Ihr solltet nun ein neues Verzeichnis mit dem Namen saltstack-vagrant-example haben. Wechselt auf der Kommandozeile in dieses Verzeichnis und gebt folgendes ein:

 $ vagrant up

Wie im vorherigen Beispiel wird zunächst das Image bezogen und gestartet. Daraufhin wird das Image gestartet und die SaltStack-Konfiguration ausgerollt. In diesem Fall wird die Datei top.sls aus dem Verzeichnis saltstack/salt gelesen und angewandt. In diesem Beispiel wird eine MySQL Datenbank installiert und eingerichtet.


Um das Konfigurationsmanagement von SaltStack ausgebiebig testen und anwenden zu können, bietet es sich an, schnell und einfach neue Linux Images installieren zu können. Dafür eignet sich Vagrant. Das Zusammenspiel von Vagrant und SaltStack ist denkbar einfach und wurde exemplarisch aufgezeigt.

Wir wünschen euch viel Spaß beim testen und bauen eurer ersten SalstStack Orchestrierung.

Logo WebdriverIO

Teste deine Webseite mit WebdriverIO – superschnell und einfach!


Es gibt verschiedene Gründe, warum internetaffine Menschen gerne ein Tool haben wollen, mit dem sie programmatisch durch den Browser navigieren können. Der wahrscheinlich häufigste Anwendungsfall ist jedoch das Testen der eigenen Webseite.

Hier kommt Selenium ins Spiel!


Selenium ist ein weit verbreitetes Tool, dass es zum Beispiel Qualitätssicherern erlaubt, ihre manuellen, täglichen Abläufe einmal in Code runterzuschreiben und diese dann durch einen Knopfdruck automatisch ablaufen zu lassen. Das spart Zeit und nerven und ist sehr skalierbar, da ein einmal geschriebener Test im besten Fall nicht mehr “angefasst” werden muss und neue Tests einfach hinzugefügt werden können.

Was hat das mit NodeJS, Gulp und WebdriverIO zu tun?

Ganz einfach: Hast Du schonmal ein komplett neues Selenium-Projekt in zum Beispiel Java aufgesetzt und damit erfolgreich getestet? Konnte deinen programmierten Code noch ein anderer Mitarbeiter verstehen bzw. wusste der nächste Kollege, der vielleicht noch nie Java genutzt hat, was er gerade vor sich sieht und konnte schnell anfangen, neue Tests zu schreiben?

Antwort eines Entwicklers: “Klar! Wenn ich programmiere, versteht das jeder….auch ohne Kommentare!” – Nope, im Regelfall nicht wahr und erst recht nicht, wenn der Kollege, der damit arbeiten muss, kein erfahrener Entwickler, sondern manueller Qualitätssicherer ist.


Der eigentliche Vorteil liegt in der Lesbarkeit und Leichtgewichtigkeit von NodeJS.
NodeJS ist eine auf JavaScript basierende Laufzeitumgebung, die sich zum Entwickeln von Komplexen Servern aber auch genauso für kleine Anwendungen eignet, da sie nicht so Hardwarehungrig ist und wenig Vorkenntnisse und Konfiguration benötigt.


Zusammen mit Gulp wird selbst die ausführung und konfiguration kinderleicht.
Gulp ist ein Framework, dass es einem ermöglicht NodeJS-Anwendungen zu konfigurieren, Buildprozesse zu organisieren und generell sich das Leben mit NodeJS einfacher zu machen.


Die Spitze des Eisberges für das einfache, automatisierte Testen mit NodeJS ist dabei WebdriverIO. Dieses speziell für NodeJS entickwelte Tool ermöglicht es selbst unerfahrenen Hobbytestern, den vorhanden Code zu lesen und sogar in windeseile selber Tests zu implementieren. Ich habe mir sagen lassen, dass das sogar Spaß machen kann!

Vorbereitung / Installation

Die folgenden Schritte beinhalten eine Anleitung zum Installieren der benötigten Komponenten und das Herunterladen des Beispielprojektes zum besseren Verständnis.
Da ich selber am liebsten Ubuntu nutze, geht die komplette Anleitung davon aus, dass Ubuntu oder ein ähnliches, Linux-basiertes, System bei dir installiert ist.

Als erstes sollten wir uns NodeJS installieren, da es die Grundlage für die folgenden Schritte bildet.

Öffne den Terminal (ctrl + alt + T) und gib folgende Schritte nacheinander ein und bestätige jeweils mit Enter:

Als erstes installieren wir nvm (node version manager zur besseren versionsverwaltung von NodeJS)

curl -o- | bash

bash ~/.nvm/

Öffne nun deine .bashrc – Datei via:

nano ~/.bashrc

und füge folgendes unten in die Datei ein:

export NVM_DIR=“$HOME/.nvm“
[ -s „$NVM_DIR/“ ] && . „$NVM_DIR/“ # This loads nvm

So haben wir dafür gesorgt, dass du auch bei einem Neustart nvm als Befehl im Terminal verwenden kannst.

Jetzt installieren wir via nvm NodeJS mit folgendem Befehl
(Zum Zeitpunkt des Schreibens dieses Blogs war die version 5.6.0 die neuste Version, weshalb wir diese verwenden werden.)

nvm install 5.6.0

Haben wir NodeJS so installiert, wurde bereits npm mitinstalliert.
npm ist das package-system von node, was uns später ermöglicht, weitere Libraries, die wir unter der Haube nutzen, zu laden und zu verwenden.

Wenn alles funktioniert hat, sollte man bei jeder der folgenden drei Eingaben im Terminal eine Version angezeigt bekommen:

nvm –version

node -v

npm -v

Als nächstes clonen wir das öffentliche Projekt, das ich auf erstellt habe, um die richtige Ordnerstruktur zu haben.

Dafür brauchen wir als erstes git (git ist das wohl am weitesten verbreitete Versionierungstool, das wir hier benötigen, um das Projekt, das von mir erstellt wurde herunterzuladen)

sudo apt-get install git

Dann “clonen” also laden wir uns das projekt in den Ordner, in dem wir uns im Terminal gerade befinden. Wenn es ein andrer Ordner, wie zum Beispiel “projects” werden soll, erstellen wir diesen vorher via dem Terminal:

mkdir ~/projects

(Das Tilde-Zeichen “~” steht für den home-Ordner des momentanen users. Der erstellte Ordner landet also unter /home/[derEingeloggteUser]/…).
Nun navigieren wir in den so erstellen ordner

cd ~/projects

…und clonen das Projekt.

git clone

Ist git damit fertig, navigieren wir in den so erstellten Ordner.

cd wdio-mocha-example

Hier müssen wir erstmal dafür sorgen, dass node alle Abhänigkeiten lokal herunterlädt, um diese während des testens nutzen zu können:

npm install

Als nächstes installieren wir Gulp global, damit wir es im terminal direkt benutzen können:

npm install -g gulp


Wir haben jetzt das gesamte Projekt aufgesetzt und konfiguriert. Nun können wir die vorbereiteten Tests starten:

gulp test

Nach der Eingabe sollte im Terminal zu sehen sein, wie der selenium-standalone-server heruntergeladen wird, danach sollte sich Chrome wie von Zauberhand öffnen, auf gehen und den Webseitentitel überprüfen.

Wichtig: Hast du kein Chrome lokal installiert, kannst du in der Datei wdio.conf.js die Stelle suchen, an der browserName steht und dort das Wort ‚chrome‘ durch zum Beispiel ‚firefox‘ ersetzen.
Dann einfach nochmal “gulp test” ausführen.

Wenn du im Terminal die Aussage “2 passing” , meist in grün, lesen kannst, hat alles funktioniert!

Überprüfen wir doch einmal, was eigentlich gerade wie getestet wurde. Sehen wir uns die Datei sample.js in wdio-mocha-example/test/specs/sample/ – Verzeichnis an.


in dieser Datei wird per describe beschrieben, was in diesem Test getested werden soll.
Ich habe in diesem Beispiel zwei verschiedene Varianten der Aufrufe des webdrivers verwendet, der in dieser Datei durch die Variable browser dargestellt wird, die automatisch mit webdriverIO global gesetzt wird.

Im ersten Test nutzen wir die etwas veraltete Variante, die mit Callbacks arbeitet. Wenn wir hier also ein getTitle() ausführen, müssen wir ein Callback definieren, der durch “.then(..” hier dargestellt wird. Das kann zur folge haben, dass es zu timing-Problemen kommt, wenn man nun im Hauptstrang der Testmethode versucht, auf Variablen zuzugreifen, die erst in dem Callback gesetzt werden oder ähnliches.
Aus diesem Grund habe ich im zweiten Test die neue Variante mit Generatoren verwendet, was sich durch den Ausdruck yield zeigt. Schreibe ich vor browser.getTitle() ein yield, so wird diese Methode sequenziell ausgeführt und ich kann mir sicher sein, dass die Methode komplett ausgeführt wurde bevor die nächste Codezeile abgearbeitet wird.

So könnten wir uns noch viele weitere Testfälle einfallen lassen. Wenn du jetzt lust bekommen hast, dieses Setup für deine Seite zu nutzen, kannst du den Projekt-Ordner gerne kopieren oder das Projekt auf forken und für dich verändern.

Möchtest du zum Beispiel einige eigene Tests schreiben, so kannst du einfach einen neuen Ordner unter /test/specs/ erstellen, dort eine .js – Datei anlegen und losschreiben.

Für weitere Informationen und Beispiele, was man mit dem WebdriverIO alles anstellen kann, empfehle ich, sich die Api-Dokumentation auf deren Webseite anzusehen.

Viel Spaß beim entwickeln deiner eigenen Tests!

Unity3D unter Linux – funktioniert das?

Seit Ende August 2015 gibt es Unity3D nun endlich auch für Linux. Am 26. August kündigte Unity3D stolz den ersten experimental build an, den sich jeder kostenlos herunterladen und ausprobieren kann.

Seitdem ist viel passiert. Die Linux-Version von Unity wird – wie auch die Windows- und Mac- Versionen – regelmäßig auf den
neuesten Stand gebracht, Bugs werden behoben und die Unterstützung verbessert.

Um immer up-to-date zu bleiben, hat Unity einen weiteren Blog eingerichtet, wo sich jeder über den aktuellen Stand informieren und den neuesten Build runterladen kann: Unity on Linux – Release notes and known issues

Aufgrund meiner Erfahrung mit Unity3D durch frühere Projekte und dadurch, dass ich am liebsten auf einem Linux System arbeite, hat mich diese Nachricht sehr gefreut und ich konnte nicht anders, als es sofort auszuprobieren.


Herunterladen und installieren

Also los: Den Blog geöffnet, einmal nach unten gescrollt und die letzte Version rausgesucht.

Offiziell unterstützt Unity nur Ubuntu ab Version 12.04+. Um also die Fehlerquellen so gering wie möglich zu halten, probiere ich es auf einer stabilen Ubuntu 14.04 x64 LTS Version.

Unity liefert ein .deb Packet aus, somit ist die Installation in wenigen Schritten beendet: Runterladen und mit einem einfachen Doppelklick auf das Packet über den Package Manager von Ubuntu installiert.



Bevor Unity jedoch gestartet werden kann, muss noch eine Kleinigkeit erledigt werden: Der Grafiktreiber.

Ich habe eine einfache NVIDIA notebook Grafikkarte. Standardmäßig benutzt Ubuntu jedoch hierfür den open source Nouveau-Treiber, der keine 3D-Beschleunigung unterstützt.

Also erst einmal einen passenden Treiber installieren. Hierzu reicht es in der Regel schon aus, einen der mitgelieferten, proprietären Grafiktreiber zu verwenden, der nur über die Systemeinstellungen heruntergeladen und aktiviert werden muss.

Dazu öffne ich einfach die Systemeinstellungen -> Software & Updates -> Tab „Weitere Treiber“. Nach einer kurzen Wartezeit tauchen hier alle verfügbaren Grafiktreiber auf.
NVIDIA stellt selbst Treiber für Linux her, welche zwar nicht von der Ubuntu community verbessert, aber getestet werden können.

Hinweis: In älteren Ubuntu-Versionen befindet sich diese Funktion direkt in der Systemsteuerung unter „Weitere Treiber“ oder „Hardware-Treiber“

Ich wähle also einen passenden Treiber (möglichst mit dem Vermerk „getestet“) und wähle „aktivieren“.

Bei den meisten Grafikkarten sollte dies ohne Probleme funktionieren. Falls es Probleme gibt, kann es sein, dass der Treiber manuell installiert werden muss. Dazu gehen Sie am besten auf die Herstellerseite der Karte und suchen nach einem passendem Treiber.

Eine Anleitung zum Installieren von Grafiktreibern unter Ubuntu ist hier zu finden.


Der erste Versuch, die ersten Probleme

Nachdem ich also den Treiber installiert habe, direkt der erste Versuch, Unity3D zu starten.

Unity3D wird bei der Installation versuchen, in der Symbolleiste das Start-Icon für den Unity3D Editor zu erstellen.

Falls ihr Unity direkt starten wollt, findet ihr die ausführbare Datei hier:


Nach dem Start erscheint der gewohnte Unity-Splashscreen und: Es passiert nichts.
Nach 5 Minuten Wartezeit hat sich immernoch nichts bewegt. Es erscheint nachwievor nur der Splash-Screen und ein Fenster mit dem Titel „recent“.




Also erst einmal in die Log-Datei geschaut. Diese befindet sich unter



Hier finde ich zwei verdächtige Einträge:

CopyPackageFile failed, unable to copy /opt/Unity/Editor/Data/Resources/Packages/unity-editor-home-0.0.7.tgz to /home/cwichert/.local/share/unity3d/Packages/unity-editor-home-0.0.7.tgz

CopyPackageFile failed, unable to copy /opt/Unity/Editor/Data/Resources/Packages/unityeditor-cloud-hub-0.0.1.tgz to /home/cwichert/.local/share/unity3d/Packages/unityeditor-cloud-hub-0.0.1.tgz


Unity versucht, beim ersten Start, packages ins lokale share-Verzeichnis zu kopieren. Das Problem ist, auf meiner Maschine existiert der Ordner ~/.local/share/unity3d nicht.

Also: Ordner erstellen und neu probieren.
Und siehe da: nach kurzer Startzeit erscheint das Unity3D Login-Fenster.

Wir können also loslegen. Erste oberflächliche Tests zeigen erst einmal, dass es zu funktionieren scheint.
An der Oberfläche selbst hat sich nichts geändert. Es ist exakt wie die Windows- und Mac-Versionen. Fast schon zu exakt, denn an einigen Stellen sieht man noch nicht native Elemente und Fenster. Die stören zwar ein wenig der Optik, tun aber der Funktionalität keinen Abbruch.



Genauere Informationen über den aktuellen Stand der Entwicklung und bekannte Probleme, könnt ihr jederzeit
im Release-Notes post verfolgen, auf den ich bereits zu Beginn verwiesen habe.


Wer noch nie mit Unity3D gearbeitet hat, findet hier liebevoll gestaltete Video- und Texttutorials.

Happy coding!




WordPress Cache

WordPress ist ein fantastisches Tool, wenn man Inhalte auf einfache Art und Weise mit anderen, über eine eigene Internetseite, teilen möchte. Die Installation ist denkbar einfach und auch die Einarbeiten, für technisch versierte Menschen, eine Frage von Minuten.
Dank zahlreicher kostengünstiger Templates, die sich darüber hinaus auch noch stark individualisieren lassen, gibt es keinen Grund auf solch ein CMS zu verzichten.

Jedoch kauft man sich, mit der starken Unterstützung die WordPress bietet, auch immer ein wenig „Magie“ mit ein. Magie die man nur lösen kann, wenn man Jahrlang hinter den Vorhang schaut und zum Großmeister des „WordPress“ wird. Diese Zeit hat jedoch niemand.
Was also tun, wenn WordPress langsamer wird oder man durch den Cahce die Performance steigern möchte?

Im folgenden möchte ich euch aus diesem Grund gerne das WordPress Cache Plugin „W3 Total Cache“ vorstellen.

Der WordPress Cache „W3 Total Cache“

W3 Total Cache ist ein Plugin für WordPress um die eigene WordPress Webseite schneller zu machen. Dabei kann mit W3 Total Cache unter anderem der Inhalt, Datenbankergebnisse oder auch Objekte (während der Verarbeitung des Quellcodes) gecached werden. Das „Caching“ bedeutet in diesem Fall, dass bei gleichen Anfragen eines Browsers, also beispielsweise ein Page-Reload (F5) oder ein weiterer Besucher, der die gleiche Weibseite besucht, die Daten nicht neu berechnet werden müssen. Stattdessen werden diese beim erstmaligem Laden gespeichert und bei weiteren Anfragen wiederverwendet.
Dies spart enorme Ressourcen im Server und führt letztendlich zu einer weitaus schnelleren Ladezeit der Webseite.

Installation des Worpress Cache „W3 Total Cache“

W3 Total Cache kann direkt über WordPress installiert werden. Dazu müssen Sie lediglich in die Sektion „Plugins“ im Admin-Bereich wechseln. Dort suchen Sie klicken Sie auf „Installieren“ im oberen Bereich der Ansicht. Im folgenden Suchfeld auf der rechten Seite geben Sie „W3 Total Cache“ ein und bestätigen durch Enter.

Sie brauchen im folgenden lediglich „Installieren“ im gefundenen W3 Total Cache Plugin zu klicken. Daraufhin wird das Plugin installiert. Nach der Installationsroutine werden Sie gefragt ob Sie auch gleich aktivieren möchten. Dies können Sie direkt bestätigen.
Nach dem das Plugin installiert ist und auch aktiviert, sollten Sie auf der linken Seite innerhalb der Navigation einen neuen Menüpunkt sehen können.

Konfiguration von W3 Total Cache

W3 Total Cache kann nach der Installation unter dem Menüpunkt „Performance“ konfiguriert werden. Dieses Tool ist sehr mächtig und bietet eine Unmenge an Konfigurationsmöglichkeiten an. Alle zu erläutern würde den Rahmen dieses Artikels beschränken. Aus diesem Grund möchte ich im folgenden nur eine einfache Konfiguration ansprechen, die bereits helfen kann die Geschwindigkeit der Webseite drastisch zu erhöhen und Kunden, so wie auch Googles Roboter glücklich zu machen.

Dazu navigieren Sie bitte in den Bereich „General“ des W3 Total Cache Plugins. Hier haben Sie die Möglichkeit alle Unterkategorien und damit Caches und andere Beschleunigungen zu verwalten. Wir interessieren uns zunächst einmal ausschließlich für die Bereiche „Page Cache“ und „Browser Cache“.

Page Cache

Wenn Sie den Page Cache aktivieren, aktivieren Sie einen Speicher auf der Festplatte oder in der Vollversion optional auch andere Formen des Datenspeichers. Dieser Speicher wird genutzt um HTML, das erzeugt wurde, aufgrund einer Anfrage eines Users, vorzuhalten. Wenn andere oder der gleiche User die selbe URL noch einmal mit ihrem Browser anfragen, wird statt das HTML neu zu berechnen, das zwischengespeicherte HTML ausgeliefert. Dies ist in den meisten Fällen wesentlich schneller als das HTML neu zu berechnen. Ebenfalls ist es wesentlich Ressourcenschonender. Auf der anderen Seite müssen Sie sich bewusst machen, dass Änderungen an der Seite innerhalb von WordPress nicht direkt beim Kunden sichtbar werden müssen. Die Änderungen die Sie an der Seite vornehmen müssen zunächst als HTML neu berechnet werden und als Datei abgelegt werden. Glücklicherweise bietet das Plugin W3 Total Cache nach der Installation im Editiermodus einer Seite oder eines Blog-Beitrages direkt einen Link um die Seite neu berechnen zu lassen.

Gehen Sie im Menü auf „Performance“ -> „Page Cache“. Hier finden Sie weitere Einstellmöglichkeit speziell zum Page Cache. Die Standardeinstellungen sind meist ausreichend, falls man nicht tiefer in die Materie einsteigen möchte. Dennoch sollten Sie jeden Punkt durcharbeiten und mit Vorsicht aktivieren. Empfehlen würde ich folgende Punkte:

  • Cache front page
  • Cache feeds: site, categories, tags, comments
  • Cache SSL (https) requests
  • Don’t cache pages for logged in users

Ebenfalls würde ich folgende URLs bei „Never cache the following pages“ hinzufügen, insofern Sie einen WooCommerce Shop betreiben:


Browser Cache

Der Browser Cache ist ebenfalls ein Zwischenspeicher. Allerdings handelt es sich hier um einen Speicher beim Besucher Ihrer Webseite. Besser gesagt im Browser des Besuchers. Dies ist besonders wichtig, da sie auf diesen Speicher kaum Einfluss haben. Das bedeutet das wenn dieser Speicher einmal aktiviert ist und sie beispielsweise ein Bild in Ihrem WordPress ersetzen, unter gleichem Namen nur mit anderer Abbildung, kann es passieren das diese Änderung den Nutzer nie erreicht. Sein Browser wird, bei eingeschaltetem Cache, bemerken, dass er dieses Bild bereits einmal angefragt hat und somit nicht mehr von Server laden, sondern aus seinem eigenen Speicher. Auf der anderen Seite bedeutet dies eine enorme Entlastung Ihres Servers und auch eine starke Beschleunigung beim Nutzer.

Um dies zu Konfigurieren wechseln Sie zu „Performance“ -> „Browser Cache“. Folgende Optionen würde ich in der Sektion „General“ empfehlen:

In der Sektion „CSS & JS“ sind folgende Punkte praktisch:

  • Enable HTTP (gzip) compression

Alle anderen Sektionen können wie „General“ behandelt werden.

Geschwindigkeit einer Internetseite messen

Wenn Sie mit Chrome die Geschwindigkeit Ihrer Internetseite messen wollen, achten Sie darauf das Sie die Developer Tools installiert haben. Ist dem so, können Sie auf einer beliebigen URL rechts klicken und „Prüfen“ auswählen. Wenn Sie nun den oberen Tab „Network“ wählen und Shift und F5 drücken, wird die Seite vollständig neu geladen. Chrome zeigt Ihnen im Tab Network welche Ressourcen geladen werden und wie lange das laden der gesamten Seite dauert.

Diese Analyse eignet sich um die Geschwindigkeitssteigerung, bzw. die Auswirkungen durch W3 Total Cache beurteilen zu können.


W3 Total Cache kann die Geschwindigkeit der eigenen WordPress Webseite enorm steigern und die Last auf den Server stark reduzieren. Durch viele weitere Optionen sind dem kaum Grenzen gesetzt. Zusammen mit der kommerziellen Variante und einem eigenen auf Webseiten optimierten Cache, haben Sie in Windeseile eine Webseite, die große Lasten verträgt und den Google Roboter sehr glücklich machen.

Neue Unicorn-IT Webseite

Nach einiger Zeit, die gefüllt mit Arbeit und internen Projekten war, kamen wir dazu endlich die Webseite neu zu gestalten.

Screenshot der neuen Webseite

Webseite Unicorn-IT

Webseite Unicorn-IT

Vor der neuen Webseite

Zuvor wurde wir die Webseite in Eigenarbeit mit AngularJS und Less entwickelt. Dabei setzten wir auf Node.js und Grunt als Build-Tool. Das funktionierte gut und half uns schnell die Webseite so zu gestalten, wie wir sie brauchten. Doch sobald wir Beiträge verfassen wollten sahen wir uns mit HTML und CSS auseinandergesetzt, obwohl der Fokus dem Text galten sollte. Es war der Beginn sich nach alternativen System umzuschauen. Mit WordPress fanden wir ein System, das unseren Ansprüchen gerecht wurde.