oliverlorenz.com

[feed] [twitter] [xing] [linkedin] [github]

Dieser Blog ist nicht kaputt.

Archive Posts

2015-01-03

Kalender abonnieren in Owncloud 7

Meine Owncloud wächst. Der Weg hin zu mehr digitaler Selbstbestimmung und weg von den Google-Diensten schreitet voran. Heute stand ich vor der Aufgabe, dass ich den Google Kalender mit dem Owncloud-Kalender zu ersetzen.

Derzeit kann Owncloud leider keine fremden Kalender abonnieren. Durch etwas googlen habe ich aber eine Lösung gefunden, die in einer Owncloud 6 Installation funktioniert.

http://zeit-zu-handeln.net/2014/02/allgemein/owncloud-6-kalender-ical-feeds-importierenexportieren/

Danke dafür! Das war meine Grundlage.

In den Kommentaren wird außerdem erklärt, wie man das Ganze auch unter Owncloud 7 zum laufen bekommt. Zusätzlich bin ich an das Problem gestoßen, dass das standardmäßige Memory-Limit beim Import meiner verschiedenen Kalendern erreicht wurde weil diese doch den einen oder anderen Termin enthält ;)

Schlussendlich hier die “ready-to-use” Datei auf Basis der Tipps aus den Kommentaren und der Original Datei, sowie meinen eigenen Verbesserungen. Diese wird nun mit einem Cronjob alle 15min getriggert wird. Ich hoffe Owncloud wird dieses Feature noch in die Oberfläche etablieren.

2015-01-25

Bye bye Wordpress

Ich nutzte bisher immer Worpress. Warum? Ja, nutzen halt alle, muss ja was dran sein. Mag sein, aber für mich ist es overpowered.

Ehrliche Worte, aber was ist meine Alternative? Meiner Alternative heißt Dropplets. Ein Blogging-Sytem ohne Datenbank auf Markdown-Basis. Das birgt den tollen Vorteil, dass ich jederzeit Blogeinträge schreiben kann auch ohne oder schlechte Internetverbindung. Reicht für mich völlig und das Backup und ein Umzug werden einfacher.

Außerdem erinnert es mich irgendwie an meine mozilo zeiten wo wir einen ähnlichen Ansatz verfolgten.

Webseite von Dropplets

Wikipedia auf dem Raspberry Pi

Wir alle nutzen Wikipedia. Auch wenn die Wikipedia als zentrale Enzyklopädie gedacht und gepflegt wird, ist es meiner Meinung nach wichtig, dass diese nicht nur auf den Servern der Wikipedia machern läuft, sondern diese auch bei evtl. Angriffen oder sonstigen Szenarien weiterhin verfügbar bleibt. Deswegen habe mich dazu entschieden die Wikipedia einfach mal zu spiegeln.

Kiwix

Was das denn?! Dazu lassen wir das Projekt mal selbst zu wort kommen

Kiwix ermöglicht es dir Zugriff auf die gesamte Wikipedia zu haben, egal wohin du gehst! Auf einem Schiff, in der Mitte von Nirgendwo oder im Gefängnis, Kiwix schafft dir Zugang zum gesamten menschlichen Wissen. Du benötigst kein Internet, alles ist auf deinem Computer, deinem USB Stick oder deiner DVD gespeichert! (Quelle: http://www.kiwix.org/wiki/Main_Page/de)

Offline? Ja und Nein. Kiwix bringt neben einer GUI einen webserver mit den man natürlich auch online nutzen kann. Ob dieser bei mehr als einem Nutzer performant ist, habe ich nicht getestet.

Installation

Ab in die Konsole. Wir befinden uns als User pi auf dem pi.

1. Neuen Nutzer anlegen

sudo adduser kiwix

2. kiwix server (ARM) herunterladen, auspacken, aufräumen. Bitte sucht euch hier die aktuellste Verion heraus. Wir nutzen hier Version 0.9

sudo su kiwix
cd
wget http://download.kiwix.org/bin/0.9/kiwix-server-0.9-linux-armv5tejl.tar.bz2
sudo tar -xjvf kiwix-server*
rm kiwix-server*

3. Rechte

exit # du bist jetzt wieder mit dem pi user unterwegs
sudo visudo
kiwix ALL=NOPASSWD: /home/kiwix/kiwix-serve
sudo nano

4. Und die Daten?

Nichts leichter als das! Hier runterladen:

http://www.kiwix.org/wiki/Wikipedia/de

Wir arbeiten in diesem Tutorial mit folgendem Download:

http://download.kiwix.org/zim/wikipedia_de_all_nopic.zim

Achtung: Die Pakete sind mehrere GB groß! Viele Gigabyte!

5. run forever. Go!


sudo nano /etc/rc.local

Hier einfach nach der Zeile “exit 0” suchen und folgendes DAVOR einfügen. Achso: Der Port ist frei wählbar. die

sudo -u kiwix /home/kiwix/kiwix-serve --port=8003 --daemon /mnt/kiwix/libraries/wikipedia_de_all_nopic_2014-11.zim

6. Reboot, have fun

sudo reboot
2015-02-13

Bluetooth aktivieren unter Ubuntu 14.10

Irgendwie ist mein Bluetooth kaputt. Keine Ahnung warum das auf meinem Lenovo T440s nicht von Werk an funktioniert aber was solls. Selbst ist der Mann!

Durch etwas googlen konnte ich das Problem lösen. Hier meine Zusammenfassung:

sudo rfkill unblock bluetooth sudo gedit /etc/bluetooth/main.conf

In der main.conf muss man den Wert für “RememberPowered” (einfach danach suchen) von true auf false stellen.

Außerdem habe ich meinen Nutzer zur bluetooth Gruppe hinzugefügt …

sudo usermod -a -G bluetooth $USER

… und das interface neugestartet:

sudo hciconfig hci0 up

Anschließend noch einen reboot und mein Bluetooth ist schon beim Start aktiviert. Toll! Endlich kann ich Spotify wieder am Rechner nutzen!

2015-03-21

Spartakiade 2015

Ich habe mich letztes Wochenende mal wieder aus dem schönen Hamburg nach Berlin gewagt. Zur Spartakiade 2015. @andrelanger hatte mich gefragt ob ich Lust habe und hat zu meiner Überraschung gleich das gesamte damalige Team mit David Jobst und Ronny Poller zusammengetrommelt. Eine schöne Überraschung und es war nicht die letzte.


Zugegeben. Ich bin etwas unvorbereitet angekommen. Die Tage davor waren stressig und ich hatte schon die Befürchtung, dass ich keinen meiner Workshops mitmachen kann, weil mit die entsprechende Hardware fehlte.

Aber erstmal zur Sparka… Spartakiade (welch Hashtag unfreundliches Wort!) ist eine relativ kleine Konferenz mit knapp über hundert Teilnehmern. Trotzdem hat man sich viel vorgenommen, denn hier geht es nicht um das simple anreißen und inspirieren eines bestimmten Themas ala CodeTalks, sondern es geht um “knallharte” Workshops wo man etwas tiefer an die Thematik herangeführt wird. Etwas besonderes wie ich finde!

In meinem Fall hatte ich mich für “Internet of the Things” und (spontan! Danke an Gregor) “AngularJS” entschieden. Dazu unten dann mehr.


Zum Start 10:00 Uhr wurde noch einmal kurz erklärt worum es geht und wie sie entstanden ist. Danach wurden die einzelnen Workshops und deren Coaches vorgestellt und schon ging es los! Darüber hinaus ist auch nochmal den Organisatoren zu Danken die neben der Arbeit im vorhinein, immer im Hintergund wuselten und für uns arbeiteten (Ja, das blieb nicht unbemerkt). Lobend zu erwähnen ist außerdem das Catering welches durch die Anzahl der Leute trotz Bemühungen einfach nicht zu packen war!

Internet of The Things

Den Workshop hat Johannes Hoppe gehalten. Intel hat uns freundlicherweise die komplette Hardware zur Verfügung gestellt. Damit waren meine Anfangssorgen erstmal vorbei. Bis ich feststellte, dass quasi nur .NET Leute um mich herum saßen, die demensprechend mit Windows ausgerüstet waren. Leider hatte ich mit meinem Linux PC wirklich zu kämpfen, damit ich das entsprechende Board zum laufen bekam. Zu Meiner und Linux’ Verteidigung: Es lag im Endeffekt an der Speicherkarte die man bespielen musste. Diese Lektion hat mich aber knapp 2h gekostet, wärend die anderen schon fleißig bastelten :/

Wir arbeiteten mit dem Intel Galileo Gen 2 Board mit einem Satz Sensoren von Seeed Studio Namens Groove. Ziel war es einen “Fullstack” von der Hardware bis zur App zu bauen. Das heißt: Wir haben einen Temperatursensor ausgelesen, diesen per Websocket zur Verfügung gestellt und mithilfe einer Ionic App zur Anzeige gebracht. Das ganze auf der Basis von JS bzw. NodeJS auf Serverseite. Johannes selbst hat den Workshop auf Github zur Verfügung gestellt, was das ganze im Detail viel besser erklärt als ich das kann.

Auf jeden Fall bin ich total geflashed was das Arbeiten mit Arduinos angeht. Ich hätte nie gedacht, dass es so einfach (und günstig) ist, Hardware etwas beizubringen und wirklich sinnvolle Dinge damit zu tun. Bisher habe ich mich nicht so richtig an Hardware herangetraut. Das hat das Eis gebrochen! :) Vielen Dank an dieser Stelle nochmal, Johannes.

AngularJS

Den AngularJS-Workshop wollte ich Dank des Workshops am Vortag unbedingt machen. Und auch das hat sich voll gelohnt. Gregor hat uns beigebracht wie wir uns in diesem mächtigen Framework zurechtfinden. Wir sind Schritt für Schritt vorgegangen und haben uns von Databinding bis Routing alles angeschaut und implementiert. Für mich als AngularJS-Anfänger genau die richtige Geschwindigkeit und schön aufgebaut! Und trotz des “kurzen” Einblicks bin ich, glaube ich, nun in der Lage, meine erste AngularJS Seite zu implementieren. Coole Sache!

Ich war wirklich wieder begeistert was heutzutage mit Frameworks möglich ist. Wie ich mir früher die Finger gebrochen habe um eine Single-Page zu bauen. Kein Vergleich zu heute. Danke an Gregor für den gelungenen Einblick! Ich bleib dran.

Fazit

Kurz und knapp: Es war grandios! Ich komme wieder! Mehr muss man da nicht sagen! Ihr solltet nächstes mal auch dabei sein! :)

2015-03-23

Apache Listing rekursiv herunterladen

Das der Apache Verzeichnisse listet ist eine Eigenschaft die sehr schön ist. Leider auch unglaublich unkomfortabel, denn im die darin beinhaltenden Dateien müssen alle einzeln angeklickt werden um diese herunterzuladen. Aber Linux und seine Tools schaffen Abhilfe.

Zu Windows-Zeiten hätte ich mir vermutlich die Finger gebrochen um gleiches zu erreichen. Oder kennt ihr ein Tool unter Windows was komplette Verzeichnisstrukturen eines HTTP-Servers synced?

Das kleine tool wget hat mir mal wieder sehr weiter geholfen. Was ich nicht wusste: Es gibt einen Parameter -m bzw. –mirror der rekursiv alle Links durchgeht und diese in der Struktur ablegt. Unglaublich praktisch. Lange Rede kurzer Sinn:

wget -m -np [URL]

Und schon rattert wget das Komplette Verzeichnis herunter. -np steht dabei übrigens für “no parent” was soviel heißt wie gehe keine Verzeichnisstrukturen hoch. Einfach und elegant.

Kennt Ihr andere Möglichkeiten? Vielleicht auch unter Windows?

2015-03-26

Bye bye Dynamic Page - Interation 2

Waaaas? Schon wieder die Webseite auf ein neues System umgezogen? Ja! Weil der erste Versuch nicht vollständig zuende gedacht war!

Weil ich nicht mehr “nur” bloggen will und der Gedanke mit der drastisch vereinfachten Seite noch nicht weit genug gedacht ist. Mein Ziel war es meine Webseite von meinem Server runterzunehmen und auf einem Raspberry Pi zu hosten. Diesen Umzug kann man mit Dropplets durchaus als Erfolg werten, denn genau das habe ich erreicht. Leider sind die Ladezeiten durch den PHP Interpreter auf dem Raspberry Pi nicht wirklich optimal.

Deswegen habe ich mich dazu entschieden, die Seite komplett statisch auf dem Webserver laufen zu lassen, was für mir keinerlei Nachteile bringt, denn das einzig dynamische (die Kommentare) werden per JavaScript eingebunden.

Und ganz unter uns: Wozu muss ein einfacher Blog und vielleicht ein bisschen Infos zu mir selbst jedes mal dynamisch gerendert werden. Das ist übrigens auch eines der Web-Szene heutzutage: Alles wird dynamisiert. Kann man ja machen, aber bitte nur da wo es sinnvoll ist.

Jekyll

Nun ist es ja nicht so, dass ich das dynamische verteufele. Ganz im Gegenteil. Ich werde mir auch jetzt nicht die Arbeit machen und bei einfacher Änderung alle Seiten anzupassen. Ich verlagere den dynamischen Teil einfach auf einen einzigen Generations-Prozess. Mein Tool der Wahl ist dabei Jekyll.

Warum Jekyll? Einfache Antwort, ich habe mich über die Features informiert und es hat die meisten Stars auf GitHub. Einfache Sache. Da ich nicht alles from-scratch selbst machen wollte habe ich mir zusätzlich ein Layout besorgt und es nach meinen Bedürfnissen angepasst.

Fazit

Ich glaube nun bin ich gerüstet. Der Raspberry Pi liefert nur noch statische Files aus und ich kann durch einen einfachen Deploy neue Blogposts schreiben. Ich bin sehr zufriesen mit dieser Lösung!

Welche Blog / CMS-Engines nutzt ihr? Und: Seit ihr der Meinung, dass es genau das richtige für euch ist?

2015-04-16

CodeForHamburg

Heute habe ich zum ersten mal CodeForHamburg besucht. Eine von vielen lokalen Gruppen die gemeinsam Anwendungen und Visualisierungen rund um offene Daten entwickeln.

Ronny Hartenstein besucht seit längerem CodeForChemnitz und erzählte mir wie toll es da ist. Meine Vorfreude war riesig. Vielleicht etwas zu groß, denn schlussendlich gehe ich mit einem gemischten Eindruck nach Hause. Warum und was ich gern verbessern möchte: Dazu unten mehr.

Die Nerds unter sich

Der nicht vollständig positive Eindruck ist wohl vor allem an meine übersteigerte Erwartung geknüpft. Ich bin tatsächlich etwas unvorbereitet angekommen und hatte die Hoffnung gleich in ein existierendes Projekt einzusteigen um Anschluss zu finden.

Am Anfang bin ich etwas schüchtern, habe dann aber gleich zwei Leute kennengelernt die ebenfalls neu und etwas orientierungslos (wie ich) schienen. Mit einer existierenden Idee waren sie mir voraus. Und somit hatten wir zumindest einen Einstieg :)

Die Idee drehte sich um einen politischen Kontext. Es geht darum Politiker-Aussagen auszuwerten und deren letztendliche Stimme bei der Wahl übereinander zu legen.

“Passt das noch? Steht derjenige als Volksvertreter zu seinen Aussagen? Gab es einen Parteizwang usw.”.

Spannend und technisch herausfordernd, wie ich finde. Schlussendlich habe ich heute aber nichts praktisches gemacht, was ich mir ein bisschen anders vorgestellt hätte.

Mein Tipp:

Mein Tipp an euch: Geht auf jeden Fall hin und bringt eine Idee mit.

Fragt euch was euch in eurer Stadt stört.

Informiert euch schon mal ob Daten öffentlich verfügbar sind. Wenn nein, kümmert euch darum, dass sie es werden. Und wenn nicht dann beißt euch auch nicht an einer Sache fest.

Mit offenen Augen durch die Stadt

Ich werde die nächsten Tage verstärkt die Augen offen halten, was mich an Hamburg stört. Und dann werde ich es bei der nächsten Runde bei CodeForHamburg besser machen. Vielleicht spreche ich auch mal das Onboarding an. Ich glaube da kann man mit ein paar kleinen Hebeln noch viel erreichen :)

Wie sind eure Erfahrungen mit CodeForGermany? Seit ihr schon mal da gewesen? Oder: Was kann man in eurer Stadt mit vermeintlich offenen Daten verbessern?

2015-05-11

Open Source Entwicklung, aber richtig!

GitHub ist toll. Immer wenn ich ein Problem habe schaue ich erstmal ob jemand anders das Problem schon gelöst hat. Habe ich ein Problem gelöst, dessen Lösung ich sinnvoll erachte anderen zur Verfügung zu stellen, schiebe ich diesen Code auch auf GitHub. Halbherzig wie ich jetzt festgestellt habe. Aber ab jetzt mache ich es besser!

Open Source Entwicklung ist mehr als Code online stellen. Open Source soll einen Mehrwert bringen und man sollte sich sicher sein, dass die Qualität auch dem entspricht wie man selbst gern Code vorfinden würde. Das heißt nicht dass der Code perfekt sein muss um online gestellt zu werden. Auch halbgarer Code hat seine Berechtigung, sollte aber als solcher zu erkennen sein.

Mein aktuelles Projekt React PHP MQTT zeigt den Weg den ich demnächst gehen möchte. Ich glaube, es schafft eine hohe Transparenz bei den Usern und schafft gleichzeitig vertrauen in die Sache. Ich möchte hier eine kleine Zusammenfassung geben auf welche Komponenten ich mich hier beziehe:

Lizenz

Code, den man verwenden kann, sollte immer eine Lizenz haben. Das bringt Vorteile und Sicherheit für beide Seiten. Ich scheute mich bisher immer etwas vor Lizensierung, denn Rechtswissenschaften sind wirklich nicht mein Fachgebiet. Mir hat die Seite www.addalicense.com geholfen. Hier kann man schnell einen Überblick bekommen welche Lizenz in welchem Fall zum Einsatz kommen kann.

UnitTest

Nichts ist schlimmer als vielversprechender Code der im Endeffekt nicht funktioniert. Die Erwartung ist groß, aber ebenso auch die Enttäuschung. Um dieses Problem zu umgehen arbeite ich folgendermaßen: Ich selbst arbeite nach etwas nachdenken erstmal darauf los. Sobald ich aber einen grundlegend funktionierenden Weg gefunden habe fange ich an Test Driven neue Milestones zu erarbeiten. UnitTests sind dabei kein Allheilmittel, aber es zeugt davon, dass sich jemand Gedanken gemacht hat und längerfristig Interesse an dem Code hat.

Travis CI

Auch das habe ich gerade erst frisch entdeckt. GitHub Projekte sind sehr einfach mit Travis CI verknüpfbar. Travis ist ein Buildserver der automatisch eure UnitTests ausführt und euch darauf eine kleine Badget Grafik bereitstellt, die ihr wiederrum in eure README.md eintragen könnt. Dem Nutzer ist dann sofort ersichtlich ob alle Unittest erfolgreich durchlaufen. Wenn nicht, dann bekommt ihr zusätzlich eine Mail und seid informiert.

Codeclimate

Codeclimate schaut etwas tiefer in euren Code und testet diesen nach diversen Clean Code Standards. Außerdem wird die Testabdeckung geprüft. Auch hier lassen sich wieder Badgets einbinden, die Rückschlüsse über die Codequalität zulassen. Eine wichtige Metrik, wie ich finde.

Packagist (PHP)

Jeder PHP’ler kennt packagist.org und liebt es. Die einfache Einbindung von Open Souce Packages. Ihr wollt dass euer Projekt genutzt wird? Legt es an!

Meiner Meinung nach solltet ihr euch immer die Frage stellen wie ihr Code vorfinden wollt. Wie bemesst ihr die Qualität von Code wenn ihr das erste mal eine fremde Library nutzt? Euer Code ist euer Aushängeschild. Vor alles Open Source Code lässt tief blicken wie gut ihr seid und wie ihr tickt. Also macht etwas daraus.

Wie versteht ihr den Open Source Gedanken? Hat jeder Code seine Berechtigung online zu stehen, oder sollte man einem gewissen Anspruch genügen? Wie läuft das bei euch?

2015-10-28

Developer Open Space 2015

Was ist das?

Der Developer Open Space ist eine Unkonferenz. Das schöne an Unkonferenzen ist, dass vorher nicht bekannt ist zu welchen Themen es überhaupt Talks geben wird. Und: Jeder ist dazu angehalten etwas beizutragen oder aktiv Themen anzustoßen über die man mit anderen ins Gespräch kommen möchte.

Was für einige Leute abschreckend und unkonkret klingt, fördert meiner Meinung nach die Kommunikation und zieht einen besonderen Typ Mensch an, was mir sehr, sehr angenehm war.

Ich möchte in dieser kleinen Blog-Reihe einen kleinen Einblick geben, wie ich diese Konferenz wahrgenommen habe und warum der Developer Open Space für mich nächstes Jahr definitiv ein Pflichtveranstaltung ist.

Organisation

Die Konferenz selbst fand in einem Tagungshotel Namens “Commundo Tagungshotel” in Leipzig statt, welches sich sehr gut für dieses Event eignete. Parkplätze waren ausreichend vorhanden, ebenso war es möglich direkt Hotelzimmer zu beziehen. Wir hatten insgesamt 7 Räume verschiedener Größe zur Verfügung. Das Rundum-Sorglos-Paket aus der Feder des Torsten Weber.

Torsten ist dieses Jahr alleiniger Organisator gewesen. Wie ich gelernt habe ist das aber nach acht Jahren Developer Open Space die Ausnahme und hat sich im Endeffekt nicht anders ergeben. Ich habe Torsten wieder als Innovator wahrgenommen, der das Talent hat Dinge einfach zu delivern, die Zügel an den entsprechenden Stellen straff zu halten und trotzdem eine gewisse Leichtfüßigkeit und Gelassenheit an den Tag zu legen. Anders hätte man dieses Event wohl auch nicht auf die Beine stellen können. Einen besonderen Dank an dieser Stelle an ihn!

Aufbau der Konferenz-Tage

Die Konferenz teilt sich in zwei Grundlegend unterschiedliche Teile.

Der erste Tag ist ein ist ein Workshop-Tag. Das heißt in diesem Fall, dass ein oder mehrere Coaches einen Workshop vorbereiten und mit den zuvor angemeldeten Teilnehmern durcharbeiten. Da geht es von Agile-Themen oder reinen Kommunikationsthemen bis in in tiefe Technologie-Topics. Das klare Motto dieses Tages ist Mitmachen und Deep-Dive!

An den anderen zwei Tagen werden in einer mehr oder minder festen Timeline so genannten “Spaces” abgehalten. Spaces sind nicht definiert. Es kann ein klassischer Talk sein, ob vorbereitet oder nicht. Eine Diskussionsrunde, ein Erfahrungsaustausch, oder eine Art Workshop im Kleinen Maßstab sein. Der Phantasie sind keine Grenzen gesetzt! Ebenso ist es möglich einfach zu sagen, dass man an einem bestimmten Thema Interesse hat.

Zum ersten Mal da?

Leuten die das erste mal da sind möchte ich ans Herz legen: Seid offen. Es ist ein Open Space. Lasst euch treiben und kommt ins Gespräch! Keiner beißt und die meisten der anderen Nerds haben noch viel mehr Angst vor euch als ihr vor ihnen ;) Ein Guter Ort dafür war mal wieder der “Snack-Raum”. Ich habe ihn liebevoll das Füllhorn getauft: Denn gefühlt hat man einen Keks rausgeholt und es wurden drei nachgelegt. Unglaublich!

Die Blogreihe

Nun habe ich zu den eigentlichen Themen noch garnicht viel gesagt. Es ist aber auch so viel zu sagen! Deswegen habe ich mich entschieden das ganze Aufzuteilen.

In meinem nächsten Teil meiner Blog-Reihe werde ich etwas zu dem Workshop-Tag und meiner persönlichen Erfahrung zu diesem Tag schreiben.

Developer Open Space - Der Workshop Tag

Dieses ist der zweite Teil der Blog-SerieDeveloper Open Space”. Zuvor habe ich bereits allgemein über die Konferenz geschrieben. In diesem Teil möchte ich genauer auf den Workshop-Tag eingehen.

Das Schöne am Workshop-Tag ist, dass man tatsächlich nicht nur einen groben Überblick bekommt, sondern wirklich per Deep-Dive in ein Thema einsteigt und tatsächlich praktische Erfahrung sammelt. In meinem Fall habe ich mich im Vorhinein für den Workshop “Microservices in der Praxis” von Andreas Helmberger und Mike Bild entschieden, welcher mich in der Umsetzung und Dynamik sehr positiv überrascht hat.

Im Workshop “Mircoservices in der Praxis” ging es darum, über mehrere Teams hinweg eine Microservice-Architektur aufzubauen und einen kleinen Online-Shop live zu bringen. Eine nicht ganz kleine Aufgabe für einen Workshop von 8 Stunden Länge.

Bevor es richtig losging wurde uns eine kurze theoretische Einführung gegeben und die vorbereitete Infrastruktur gezeigt. Uns wurde ein vorbereiteter Docker-Container zur Verfügung gestellt, in dem eine NodeJS-Instanz lief, die wir nutzen konnten. Darüber hinaus gab es einen TravisCI, der das ganze dann in die Cloud deployed. Das hatte zum einen den Vorteil, dass wir sofort loslegen konnten, zum anderen haben wir damit das etwas lahmende WLAN zum Teufel gejagt, da alle breitbandintensiven Operationen in der Cloud stattgefunden haben. Großes Kompliment! Richtig gut und gleichzeitig praxisnah umgesetzt!

Der erste Teil des Workshops war am Anfang etwas holprig. Das lag aber mehr an den anwesenden Leuten als an den Speakern. Alle beschnupperten sich erstmal ein wenig. Wir diskutierten wie wir das ganze aufbauen wollten. Ich habe diesen Teil vor allem als Verständnisschärfung innerhalb der Gruppe für eine Microservice-Architektur wahrgenommen.

Ich persönlich habe die Diskussionszeit ein bisschen schleppend wahrgenommen. Man hätte an der Stelle meiner Meinung nach gern etwas flotter durch diese Diskussion gehen können. Das Thema war mir allerdings auch nicht ganz neu. Das Endergebnis war Schlussendlich sehr positiv. Ich hatte das Gefühl, dass jeder Workshop-Teilnehmer wusste was zu tun ist.

Nachdem wir festgelegt hatten wie wir die Services schneiden, haben wir Teams gebildet, die sich jeweils um einen Service kümmerten. In unserem Fall haben wir uns für folgenden Schnitt entschieden, um unseren E-Commerce-Shop auf die Beine zu stellen:

Die Aufteilung der Teams ging schnell. Einzig und allein der UI-Service schien unter den Workshop-Teilnehmer nicht so beliebt zu sein. Um das Ganze voranzutreiben habe ich mich dafür entschieden diesen Teil zu übernehmen, worauf sich ein zweiter Teilnehmer anschloss.

Startschuss in die Praxis

Das wichtigste am Anfang war es, dass jeder deployen konnte. Zur Unterstützung wurde ein physisches Board erstellt wodurch angezeigt werden sollte, ob man bereits deployen konnte oder nicht.

Wie bei Microservices selbst, sind einige Absprachen notwendig um ein vernünftiges Service-Ökosystem auf die Beine zu stellen. Es müssen IP-Adressen, Protokolle und Formate definiert werden. Ich hatte den Eindruck, dass diese Diskussion sehr viel Zeit in Anspruch genommen hat und immer sehr dezentral verlaufen ist. Das Ergebnis war im Endeffekt, dass die linke Hand nicht wusste was die Rechte tut. Nichtsdestotrotz haben es alle Teilnehmer geschafft, ihren Service zu deployen.

Eine Microservice-Architektur ist ein lebendes Konstrukt. Vor allem als UI-Team, welches alle Services miteinander verbindet, standen wir immer wieder vor Problemen:

Um diesen Problemen von Anfang an entgegen zu wirken, haben wir uns dazu entschieden in der ersten Version die entsprechenden Endpunkte zu mocken. Das hatte den Vorteil, dass wir nicht durch die anderen blockiert waren und uns nicht ständig anpassen mussten.

Somit waren wir in der Lage, bereits einen Produkt-Katalog anzuzeigen, wärend die anderen noch implementierten. Das Anschließen der Services haben wir dann einmalig an das Ende der Implementierung gesetzt.

Technisch war unser UI-Service eine Single-Page auf Basis von Twitter Bootstrap 3 und jQuery der über die REST-Endpoints der Services gefüttert wurde. Das entsprechende Repository kann hier eingesehen werden.

Die gesamten Repositories aller Teams sind hier zu finden.

Schlussendlich haben wir es zeitlich nicht geschafft alles zusammenzubringen. Macht aber nichts, denn ich glaube dass alle verstanden haben, worum es ging und wo die Herausforderungen lagen.

Die Speaker

Andreas und Mike haben ein super Team abgegeben. Während Andreas vor allem den technschen Teil übernommen hat, hat Mike vor allem die Rolle des Projekt-Managers eingenommen, was sich perfekt ergänzt hat.

Der Workshop war super vorbereitet! Man hatte von Anfang bis Ende das Gefühl, dass sie wissen wovon sie reden und auch schon eine gewisse Routine in der ganzen Thematik mitbringen.

Auf alle aufkommenden Fragen oder auftretende Probleme wurde eingegangen und diskutiert. Auf alles gab es eine Antwort, die uns als Workshop-Teilnehmer weiterbrachte!

Solltet ihr die Möglichkeit haben an einem Workshop der beiden Teilzunehmen: Macht es! Kann ich uneingeschränkt empfehlen!

Meine Learnings

Auch wenn es im Endeffekt dazu gefüht hat, dass wir insgesamt nicht fertig geworden sind, spiegele der Workshop die Herausforderung der Microservice-Architektur sehr gut wieder. Eine Microservice-Architektur ist from Scratch ein beherrschbares Konstrukt. Sobald es aber um Änderungen geht (und das tut es ja qausi immer), sollte man sich genau überlegen was man tut. Änderungen in einem Microservice können und werden dazu führen, dass andere abhängige Services kaputt gehen.

Besonders deswegen habe ich mitgenommen, dass man Microservices nur einsetzen sollte wo es tatsächlich notwendig ist. Microservices bieten auf der anderen Seite eine hohe Ausfallsicherheit, da - bei entsprechender Einrichtung - mehrere Instanzen parallel laufen können.

Die größte Herausforderung sehe ich bei der Microservice-Architektur in der Abstimmung der Services oder Teams untereinander. Wir haben im Worshop selbst fefstgestellt, dass zum Anfang elementare Absprachen gefehlt haben, die das Zusammenarbeiten schwierig gemacht haben. Ohne ein gewisses Regelwerk wird eine Microservice-Architektur im Chaos enden.

Fazit

Ein großartiger Workshop, in dem ich mein Wissen technisch vertiefen konnte, aber vor allem der Kommunikationsfaktor DAS Key-Learning war. Ich bin sehr froh, diesen Workshop gewählt zu haben, denn ich weiß jetzt welche Herausforderungen auf mich zukommen, wenn ich mich für eine solche Archiketur entscheide.

Insgesamt hätte ich mir ein bisschen mehr vordefinierte Regeln gewünscht. Zum Beispiel:

Das hätte uns eine Menge Zeit und Implementations-Interationen gespart, wobei man prüfen müsste ob das Learning damit immernoch so effektiv gewesen wäre.

Der Workshop selbst war sehr abwechslungsreich, unterhaltsam und vor allem kommunikativ! Ich hatte sehr viel Spaß und habe viel gelernt, was ich nun in meinen Arbeitsalltag integrieren kann! Vielen, vielen Dank dafür!

Die Blogreihe

Im nächsten Teil meiner Blog-Reihe werde ich etwas zu den Spaces-Tagen erzählen. Dabei werde ich weniger etwas zu konkreten Spaces erzählen (das wird Teil 4) sondern eher auf den allgemeinen Ablauf bzw. deren Organisation an diesen Tagen erzählen.

2015-11-01

Developer Open Space - Die Spaces

Der zweite Tag und dritte Tag beim Developer Open Space sind die Spaces-Tage. Spaces sind nicht definiert. Es kann ein klassischer Talk sein, ob vorbereitet oder nicht. Eine Diskussionsrunde, ein Erfahrungsaustausch, oder eine Art Workshop im kleinen. Der Phantasie sind keine Grenzen gesetzt! Ebenso ist es möglich, einfach zu sagen, dass man an einem bestimmten Thema Interesse hat.

Das Standup

Der Tag beginnt wie bei vielen in meinem Arbeitsumfeld mit einem Standup. Torsten hat kurz ein paar Worte zur Konferenz und deren Geschichte und Wandlung über die letzten Jahre erzählt. In diesem Moment wurde mir auch das erste Mal die Teilnehmer-Zahl von über 300 im Raum bewusst.

Im Anschluss hat er uns die “Regeln” für einen Space vorgestellt, was mich etwas zum Schmunzeln gebracht hat. Eben nicht weil ich es albern fand, sondern ich diese offene Kommunikationsförderung sehr zu schätzen weiß! Die Wichtigste war “Das Gesetz der zwei Füße”, welche aussagen sollte, dass jeder den Space verlassen kann wenn man einen Grund dazu sieht. Egal ob man einfach nur kurz in ein Thema reinhören wollte oder man sich etwas anderes vorgestellt hat. Hätte man diese Ansage nicht gemacht, hätte man wohl mehr Hemmungen gehabt einen Space einfach zu verlassen.

Nach dieser kurzen Einführung war die “Bühne” für die Teilnehmer freigegeben. Jeder, der einen Beitrag leisten wollte oder einfach ein Interesse an einem bestimmten Thema hat, konnte sich kurz vor das Publikum stellen und etwas sagen. Anschließend wurde mit Handzeichen signalisiert wie viel Interesse an dem Thema besteht. Je nach dem wurde dann ein Raum mit der entsprechenden Größe gewählt.

Nachdem alle Beitragenden gehört worden sind, hat sich eine Timetable ergeben, die inital durch Torsten unter Berücksichtigung der Raumgröße definiert wurde. Anschließend hatten wir noch einmal die Möglichkeit zu schieben und entsprechend Einfluss zu nehmen. Und schon ging der Tag los!

Dieses Schauspiel hat sich an beiden Spaces-Tagen ereignet und war die Einstimmung auf den Tag. Trotzdem gab es Unterschiede zwischen den Tagen:

Ich persönlich habe im ersten Tag für mich klare thematische Lücken entdeckt zu denen ich etwas beitragen konnte. Was ich letztendlich dann auch getan habe. Ich glaube der zweite Spaces-Tag ist bei dieser Konferenz tatsächlich der qualitativere. Zumindest habe ich wahrgenommen, dass die Leute mutiger geworden sind, selbst etwas beizutragen.

Der erste Tag hatte den Charme, dass vor allem die gut vorbereiteten Vorträge ihre Bühne fanden. Man darf nicht vergessen, dass ein guter Vortrag oder Workshop ein super Aushängeschild für jeden Web-Worker ist. Und wenn man es genau nimmt sind diese Bühnen selten.

Unterschiedliche Spaces, Charaktere und Qualitäten

Ich kann leider nicht zu allen Spaces schreiben die ich besucht habe. Trotzdem sind mir ein paar allgemeine Dinge aufgefallen auf die ich eingehen möchte.

Spaces sind nicht definiert und bieten, neben den Leuten die wirklich Routine im halten von Talks haben, auch anderen eine Plattform sich auszutauschen.

Ich hatte einige Speaker gesehen, die über ihren Schatten gesprungen sind, und einfach ein Thema angeboten haben. Oft hat man gemerkt, dass sie das noch nie gemacht haben, aber es sind super Spaces daraus entstanden. Ich habe selten so fruchtbare und dynamische Diskussionen erlebt wie beim Developer Open Space. In diesen positiven Beispielen hatte man wirklich den Eindruck, dass sich die Leute auf Augenhöhe begegneten und sich die Diskussion von ganz alleine weiterentwickelt. Am Ende konnte jeder etwas mitnehmen, egal auf welchem Wissensstand oder mit welcher Erwartung man in den Space gegangen ist.

Neben den wirklich sehr vielen guten Spaces gab es aber auch einige, die ich etwas enttäuscht verlassen habe. Die Themen waren sehr interessant und waren als offene Diskussion angedacht. Schlussendlich stellte sich aber heraus, dass das Thema vom Space-Initiator immer wieder auf seine eigene Position gelenkt wurde. Die Sätze haben eigentlich immer mit der Floskel “Bei uns in der Firma …” begonnen.

Konstruktive Beiträge sind zwar angehört worden, aber haben irgendwie nicht dazu geführt, dass sie die Diskussion befruchten. Retrospektiv betrachtet hat sich das Ganze wie ein großes Jammern angehört. Auch das muss mal sein, aber ich hätte mir gewünscht, dass man hier vielleicht etwas lösungsorientierter diskutiert.

An dieser Stelle möchte ich auch mir selbst und ggf. den anderen Spaces-Teilnehmern an die Nase fassen: Sollte es garnicht passen, sollte öfter das Gesetz der zwei Füße in Kraft treten. Andersherum ist es auch an uns Teilnehmern, den Space mehr zu formen. Das werde ich nächstes mal besser machen.

Die Blogreihe

Dieses mal bin ich vor allem auf die allgemeinen Aspekte der Spaces eingegangen. Das soll aber nicht so bleiben. Im nächsten Teil gehe ich auf meine Highlight-Spaces und meinen ersten eigenen Space ein.

2015-11-07

Developer Open Space - Meine Space-Highlights

Nachdem wir im letzten Teil über den Developer Open Space allgemein auf die Spaces eingegangen sind möchte ich dieses mal auf meine Highlight-Spaces eingehen. Nun muss man dazu sagen, dass ich maximal 1/7 aufgrund des parallelen stattfindens Talks mitbekommen konnte. Diese Übersicht ist also hochgradig subjektiv und stark an meine persönlichen Interessen gebunden.

Schnellstart mit Angular 2.0

von Johannes Hoppe und Gregor Woiwode

Mein erstes Highlight waren Johannes Hoppe und Gregor Woiwode mit ihrem Talk “Schnellstart mit Angular 2.0”. Beide kenne ich schon von der Spartakiade 2015, wo ich jeweils einen ihrer Workshops besucht habe. Aufgrund dieses Eindrucks konnte ich hier Qualität erwarten. Und ich wurde nicht enttäuscht.

Die Jungs, die sich im Space als sehr gutes Team herausgestellt haben, haben an einem vorbereitetem Beispiel eine kleine Einführung in die Änderungen und Neuerungen von Angular 2.0 gegeben. Es war informativ und hatte eine gewisse Leichtigkeit, was sehr unterhaltsam war. Den Talk selbst haben sie mittlerweile online gestellt, also könnt ihr euch selbst ein Bild machen.

Ich habe vor allem mitgenommen, dass Angular einen großen Schritt nach vorn macht. Weg von einem Overkill-“Ich vereinige alles in einem”-Framework zu einem Tool welches man als Komponente in seinem Projekt nutzen kann und einen wirklich unterstützt. Es macht Dinge wesentlich klarer und konsistenter als sein Vorgänger und setzt auf ECMA-Script 6 auf.

Die Jungs können das wesentlich besser erklären als ich mit meinem Halbwissen. Sie arbeiten gerade an einem Buch, welches sich um Angular 2.0 dreht. Nach diesem Vortrag bin ich sehr, sehr zuversichtlich, dass es sich lohnen wird, dieses zu kaufen.

Room Presence Service

von Ferdinand Malcher

Die Idee ist aus der Not geboren. Ständig kommt irgendjemand ins Büro rein um drei Sekunden später festzustellen dass der Gesuchte nicht da ist. Trotzdem ist man natürlich in dem Moment aus seiner aktuellen Arbeit gerissen. Die erarbeitete Lösung wurde auch direkt in einem Video festgehalten. Und ein Video sagt mehr als tausend Worte:

Room Presence Service from Ferdinand Malcher on Vimeo.

Irgendwie eine witzige Idee, wo man wieder mal sehen kann wie einfach man mit dem Rasperry Pi kleine Projekte umsetzen kann!

Nach dem Vortrag ist eine breite Diskussion über Homeautomation und angrenzende Themen entstanden die den Vortrag dann thematisch noch etwas erweitert haben.

Persönlichkeiten

von André Langer

Andrés Vortrag war der einzige Soft-Skill Space den ich mir angehört habe. Das erfischende an diesem Space war, dass er zwar klein, aber irgendwie genau richtig groß war, denn er entwickelte eine sehr coole Dynamik.

Unsere erste Aufgabe war es, uns eine uns real bekannte Person aus unserem Leben herauszunehmen und zwei Eigenschaften derer aufzuschreiben, welche wir an ihr schätzen bzw. nicht schätzen. Diese dabei entstandenen Karteikarten haben wir dann alle an ein Board gehangen, getrennt nach positiv und negativ.

Anschließend haben wir versucht diese verschiedenen Eigenschaften zu clustern. Dabei hat sich sehr schnell herausgestellt, dass diese Aufgabe nicht so einfach ist. Oft flammten Diskussionen auf, die die eigentliche Motivation hinter dem Verhalten der Personen beleuchteten. Zu diesem Zeitpunkt wurde mir klar, dass vermutlich niemand eine böse Absicht hinter seinem Handeln hat, sondern es viel mehr unterschiedliche Charakterliche Schwerpunkt gibt mit Problemen umzugehen, bzw. die Lösung derer zu erarbeiten.

Nachdem wir das Clustern irgendwann beendet hatten, erleuterte André das Model dahinter. Grundlegend gibt es laut diesem vier verschiedene charakterliche Hauptausrichtungen. Die Dominanten, die Innovativen, die Stetigen und die Gewissenhaften.

Der Charakter eines jeden von uns besteht aus diesen, nur mit unterschiedlicher Wichtung. Jeder von uns hat in seinem Leben die für ihn erfolgreichste Wichtung ausgeprägt und lebt - mehr oder weniger unbewusst - nach dieser gewissen Grundeinstellung. Dabei ist man aber im seltensten Fall einer Gruppe absolut zuzuordnen. Die meisten vereinen mindestens zwei Schwerpunkte.

Das Model fördert natürlich ein gewisses Schubladendenken. Was negativ behaftet klingt, hilft aber grundlegend eine Situation besser einordnen zu können und sich auf sein Gegenüber einzustellen. Beiderseits. Man kann plastischer einordnen wie der andere tickt.

Retrospektiv betrachtet, hat sich diese Einordnung bereits während des Spaces gezeigt. Es gab dominatntere Leute die die Diskussion immer wieder in eine gewisse Richtung geschoben haben. Es gab die Innovativen, die unterschiedliche Dinge plausibel zusammengebracht haben. Die Stetigen, die nicht Laut, aber immer präsent waren. Und die Gewissenhaften die uns ggf. immer wieder auf “den richtigen” Weg geführt haben.

Das Leben ist Gruppendynamik. Gruppendynamik ist etwas Gutes. Ich versuche dieses Model nun immer da anzuwenden, wo ich merke, dass ich mit meinen Zielen nicht weiterkomme. Aus diesem Blickwinkel war dieser Space tatsächlich der, der mich nachhaltig wohl am meinsten beeinflussen wird.

Mein erster Space - First Steps with Ansible

Wie schon erwähnt habe ich am ersten Tag eine für mich offensichtliche, thematische Lücke entdeckt die ich füllen konnte. Schlussendlich bin ich mir aber nicht sicher ob Ansible im .NET-Umfald überhaupt zum Einsatz kommt. Ich habe die Konferenz über immer wieder festgestellt, das man nach und nach verstärkt auf Linux-Systeme in Form von Docker-Containern setzt, das ganze Linux-System aber noch nicht so das richtige Standing hat. Und es scheint noch der Überbblick zu fehlen.

First Steps with a Space

Meine Vision war es, den Leuten eine kleine Einführung zu geben wie man mit Ansible startet, da mir bewusst war, dass in diese Richtung wohl noch nicht allzuviel Wissen da war. Ziel war es eine statische Webseite inklusive eines Nginx zu deployen.

Leider wurde mein Space etwas gehijacked. Ich hatte im Space davor eine kleine Sache vorbereitet, die ungetestet natürlich nicht auf anhieb funktionierte. Dazu kam, dass ich einen Teilnehmer im Space hatte, der sich schon etwas länger mit dem Thema auseinandersetzte und gleich alles zeigen wollte was er gemacht hat. Somit wurde eine Art Coop-Space daraus, was erstmal nichts Schlechtes war, das Ganze aber für die Teilnehmer noch abstrakter und wohl kompizierter gemacht hat. Im Nachhinein hat mich das doch etwas geärgert, da ich nicht das vermitteln konnte, was ich für die Teinehmer für wichtig erachtet habe.

Learnings

Die Blogreihe

Das war der vierte und vorletzte Teil meiner Serie. Im letzten Teil werde ich noch einmal ein gesamtheitliches Fazit ziehen und auf ein paar tolle Ereignisse neben der eigentlichen Konferenz eingehen.

2015-11-10

Developer Open Space - Fazit

In diesem Teil meiner Serie über den Developer Open Space möchte ich nochmal ein paar ganz allgemeine Worte finden und vielleicht das Ganze auch nochmal für mich zusammenfassen.

Fazit

Die Workshops haben mein Wissen dieses mal vertieft und mich vor allem im Soft-Skill-Level wieder vorangebracht. Das hat mich stark überrascht, zeigt mir aber auch hier, wie imens wichtig dieser Teil in der heutigen Softwareentwicklung ist. Diese Erfahrung hätte mir kein Buch vermitteln können!

Die Spaces waren eine schöne Erfahrung. Im aktiven und passiven Part. In beiden Fällen habe ich viel gelernt was ich im nächsten Jahr besser machen kann und möchte. Vor allem habe ich die Angst verloren, selbst etwas zu präsentieren und mein Wissen weiterzugeben. In den Kommentaren meines ersten Teils gibt es schon erste Nachfragen nach ähnlichen Formaten im Nordeutschen Raum.

Schlussendlich kann man zusammenfassen, dass es der DevSpace in allen Hinsichten Wert ist. Ich war auf Konferenzen die das fünf- bis zehnfache gekostet haben und für mich lange nicht den langfristigen Output generiert haben wie es der Developer Open Space getan hat.

Vergleicht man die Themenvielfalt, kommt man auf einer klassischen Konferenz bei einem sehr ähnlichen, wenn nicht geringerem Themen-Spektum heraus. Viele Konferenz-Speaker kümmern sich vor allem um die Hype-Themen der Szene. Ebbt das allgemeine Interesse ab, ebben auch die Talks dazu ab. Diese Nische besetzt das Spaces-Konzept wieder sehr gut, weil dieses Interessen- und Problemgetrieben ist. Die daraus resultierende Vielfalt konnten wir dieses mal genießen.

Und noch etwas ist mir positiv aufgefallen: Ich bin nicht mit brummendem Kopf aus dieser Konferenz gekommen. Klar will ich immer so viel wie möglich mitnehmen, aber der Informations-Overload den ich mir auf so manch’ anderer Konferenz zugezogen habe, blieb hier durch den lockeren Umgang und das miteinander statt Speaker-Publikum-Situation irgendwie aus. Kurzum: Ich habe die Konferenz sehr inspiriert verlassen und habe gleichzeitig wohl mehr behalten als auf den Konferenzen zuvor.

Danke!

Auch jetzt - Einige Wochen danach ist der Developer Open Space für mich immer noch präsent. Das liegt vor allem an den vielen Reaktionen, Zuschriften, Follows, Kommentaren und dem Feedback was mir über die letzten Wochen zugetragen wurde und über welches ich mich sehr freue!

Die Blogserie

Ich hoffe, ich konnte mit meiner Serie einen kleinen Einblick geben wie diese Konferenz abläuft und wo deren Stärken liegen. Ich hoffe, dass ich den einen oder anderen auf der Spartakiade 2016 oder dem Developer Open Space 2016 wiedersehe bzw. vielleicht sogar dafür begeistern konnte das nächste mal erstmalig dabei zu sein!

Sollte ich Themen nicht angeschnitten haben, ihr anderer Meinung seid oder einfach noch Fragen habt, würde ich mich freuen, wenn ihr einen Kommentar da lasst!