Heimnetzwerk – Teil 1

Heimnetzwerk

Was benötigt der Informatiker von Heute? Natürlich ein vernetztes Eigenheim.
Daher möchte ich hier meine Erfahrungen teilen. Wir bauen aktuell ein Haus und ich habe
meine Interessen in den Bau einfließen lassen. Daher werde ich hier mehrere Beiträge veröffentlichen,
angefangen von der Planung bis hin zur Realisierung.
Da es sich um unser Eigenheim handelt und diese Plattform öffentlich ist, werden keinerlei Fotos von dem Haus veröffentlicht werden.
Lediglich Beispielbilder werden hier gepostet bzw. Bilder die keine Hinweise auf örtliche Gegebenheiten hinweisen.

Die Vorbereitung

Was braucht man für ein Heimnetzwerk? Vorab natürlich ein Eigenheim, am besten Eigentum oder einen sehr
freundlichen Vermieter. Denn durch das Haus / die Wohnung müssen erstmal einige Kabel gezogen werden.

Bei einer „normalen“ Hausverkabelung wird man eine normale Sterntopologie vorfinden. Alle Kabel enden an einem
zentralen Punkt und werden dort auf ein Patchfeld aufgelegt.

Bei uns hat jeder Raum mindestens eine 2-Port CAT6A Unterputzdose der Firma Gira, je nach Bedarf.
Die Kabel haben die Bezeichnung Fairline S/FTP 8PSC23 1000 MHz und enden alle im Haustechnik-Raum.
Die Verlegung der Kabel wurden bei uns von dem Generalunternehmer der Baufirma durchgeführt. Die Kabel liegen
aktuell ungepatcht im Technik-Raum. Wichtig hierbei: Reserve lassen am Endpunkt.
Dadurch kann man ein vernünftiges Kabelmanagement einbringen und hat keine Probleme bei der Positionierung der Hardware.
Ich habe 3 Meter Kabelreserve einziehen lassen, damit ich auf der Wand genug Spiel habe. Der Rest wird im Serverschrank drapiert.

Die Hardware

Die Hardware für das Heimnetz habe ich hauptsächlich gebraucht erstanden. Warum? Weils billiger ist.
Beim Hausbau mangelt es erstmal an was? Richtig: Geld! Daher hat mir die Kleinanzeigen-Website eines
größeren Internet-Unternehmens für Auktionen weitergeholfen.

Der Serverschrank

Was will ich wo unterbringen? Das ist die elementare Frage, wenn man die Größe des Serverschranks dimensionieren möchte.
Ich möchte bei uns das Patch-Panel, einen Microserver (nicht 19″ Bauform), einen Switch (1 HE),
den Router des ISPs und ggf. Micro-Rechner a la Raspberry Pis unterbringen. Daher benötige ich einen Schrank mit mindestens 14 HE.

Gesucht gefunden:
Ein Anbieter eines gebrauchten Server-Schrankes in Moers hat im Portal inseriert.
Das gute Stück soll für 50 € den Besitzer wechseln. Als kleines Schmankerl gibts eine Schuko-Steckerleiste (1 HE) und eine Lüftersteuerung dazu.
Vor Ort wurde der Serverschrank im Keller des Anbietes inspiziert.
Der Schrank stammt aus einer Tankstelle und stand wohl kurzzeitig auf einem Hof.
Dieser war dementsprechend dreckig und war oberflächlich rostig, außerdem wurde ein Stück der Rückenplatte rausgeschnitten.
Aber eine Regalplatte war noch zusätzlich drin. Also gekauft und nach Hause gebracht.

Heute wurde der Schrank größenteils gereinigt und vom Rost befreit. Das Ergebnis kann sich sehen lassen. Oben sieht man die noch
nicht gereinigten Platten.

Als nächsten Schritt folgt die Reinigung und Zerlegung der Steckerleiste. Achtung: Die Steckerleiste wird später 230V führen und sensible
Technik mit Strom versorgen. Also ist Vorsicht geboten.
Nach der Zerlegung wird die Lüftersteuerung rausgeholt und ebenfalls gereinigt.
Alle gereinigten Teile werden ohne die endgültige Hardware getestet. Dazu später mehr.

Das Patchpanel

Für die Patchkabel benötigt man natürlich auch ein passendes Patchfeld. Auch hier wurde ich bei den Kleinanzeigen recht schnell fündig:

Ein CellPack Cat6a Patchpanel mit 24 Ports für 5 € plus 3,50 € Versand wurde angeboten. Direkt bestellt und 3 Tage später war es da.
Der Verkäufer hat sich das Entfernen der Kabel gespart, aber mit einem LSA+-Werkzeug und einem Seitenschneider waren die Kabelreste fix entfernt.
Jetzt wartet das Patchfeld auf seinen Einsatz im Haus. Cellpack scheint heute keine Patchfelder mehr herzustellen,
daher kann ich leider keinen Link zur Produktseite angeben.

Man sollte sich an dieser Stelle einen Elektriker ranholen, der die Kabel auf das Patchfeld auflegt und die passenden Messgeräte besitzt,
um etwaige Fehler im Kabel zu lokalisieren. Das Prüfprotokoll sollte man sich dann aushändigen lassen, da man das für Gewährleistungsansprüche benötigt.

Der Switch

Ich liebe intelligentes Spielzeug, so auch alle aktiven Komponenten eines Netzwerkes. Daher habe ich mich auf die Suche nach einem Managed Switch gemacht.
Am besten auch noch Gigabit-fähig und mit Glasfaserkomponenten erweiterbar. Nach einer Weile wurde ich auch hier fündig.

Aus eine Umrüstung eines Rechenzentrums wurden 6 Gigabit-Managed-Switches verkauft:
Netgear GST716T Version 1 und Version 2. V1 für 35 € plus Versand und V2 für 45 €.

Da Version 2 Green-IT zertifiziert ist und den Stromverbrauch dynamisch anpasst und auch noch leiser sein soll, habe ich mich natürlich für die neuere Version entschieden.
Leider wurde zuerst die falsche Version eingepackt und zugeschickt. Dieser Switch war so dermaßen laut, dass ich ihn habe austauschen lassen und siehe da:

Annehmbare Lautstärke und ein wundervolles Webinterface leuchteten mir entgegen. Noch schnell das Embedded System auf die neuste Version aktualisiert und fertig.

Die Einstellungen am Switch werden in einem späteren Post beleuchtet, da dieser aktuell auf seinen Einsatz wartet.

Hier der Link zum Produktdatenblatt (benötigt Adobe Reader): http://www.downloads.netgear.com/files/GDC/GS716TV2/GS716T-200_GS724T-300_DS_24Feb1218-5327.pdf

Ausblick

Das hier ist erstmal eine Übersicht aller Hardware die für das grundlegende Heimnetzwerk benötigt werden.
In einem späteren Artikel werde ich den Aufbau und die Einrichtung meines Servers beleuchten.

Microservice Management mit Istio

Die aktuelle Woche gehört mit absoluter Sicherheit zu den Wochen meines Lebens, die ich nie vergessen werde. Aktuell bin ich auf Kreta und besuche die bis dato absolut beste Konferenz, die ich je besuchen durfte: JCrete. An dieser Stelle deswegen nochmal einen großen Dank an Heinz Kabutz für die Möglichkeit teilzunehmen. Allein in den ersten zwei Tagen habe ich bereits genug interessante Themen für den Rest des Jahres kennengelernt, über die ich am liebsten alle schreiben würde. Doch da immer nervige kleine Faktoren wie Zeit dazwischen geraten, habe ich mir gedacht heute mal eines der noch unbekannteren Themen in Angriff zu nehmen.

Teil unseres gestrigen Programms war ein Ausflug an den Falassarna Strand. Ich hatte dabei das Glück von Ray Tsang zusammen mit Gerd Aschemann und Tobias Frech im Auto mitgenommen zu werden. Ich war also in bester Gesellschaft. Und wie zu erwarten kamen während der Fahrt auch die unterschiedlichsten interessanten Themen auf, von denen ich heute eines gerne in Deutsch vorstellen möchte.

Istio

Interessanter Name, nicht wahr? Istio ist ein Projekt von Google, IBM und Lyft welches sich mit einem ganzen Bündel von Problemen einer momentan typischen Microservice-Architektur beschäftigt. Wer sich durch die englische Dokumentation lesen will, findet diese hier, wer nur einen kurzen Überblick möchte, sollte bleiben 😉

Istio ist für Microservice-Architekturen entworfen worden und momentan direkt in eine Kubernetes-Umgebung integrierbar (weitere Umgebungen sollen noch folgen). Daher macht es meiner Meinung nach am meisten Sinn euch einen kleinen Überblick über Kubernetes zu verschaffen. Kubernetes ist wenn man so will ein große Bruder zu Docker: während in Docker Container bereitgestellt werden, kümmert sich Kubernetes um Bereitstellung, Skalierung und Verwaltung dieser Container in verteilten Systemen. Um das zu erreichen bietet Kubernetes eine Plattform mit ihren nochmals eigenen Strukturen.

Das Ganze startet dabei vom Cluster aus. Dieser besitzt einen Master, der sich um die gesamte Verwaltung des Clusters kümmert. Jeder Cluster kann aus einer beliebigen Anzahl an virtuellen oder physischen Maschinen bestehen, welche Nodes genannt werden. Diese besitzen wiederum jeder ihre eigene beliebige Anzahl an Pods, welche schließlich die Container mit ihren Applikationen umschließen. Selbst Zwiebeln haben nicht sonderlich mehr Schichten, weshalb diese schönen Schaubilder von Kubernetes das nochmal vereinfacht darstellen:

Kubernetes Cluster von kubernetes.io
Kubernetes Node von kubernetes.io

Was hat das ganze nun also mit Istio zu tun? Nun, Istio macht sich diese Plattform zunutze, um einige typische Aufgaben für verteilte Systeme zu erledigen. Es verspricht dabei sich um vier Schlüsselfunktionen innerhalb einer verteilten Microservice-Architektur, eines sog. Service-Mesh zu kümmern:

  • Traffic Management
  • Observability
  • Policy Enforcement
  • Service Identity and Security

Traffic Management bezeichnet dabei das Versprechen, den Informationsfluss und die Menge an API-Calls zwischen den Services auszugleichen, Aufrufe zuverlässiger zu machen und insgesamt das Netzwerk selbst für widere Umstände robuster zu halten. Hier könnten sich jetzt einige denken: „Klingt ziemlich ähnlich zu dem was Hystrix macht“. Und damit hättet ihr absolut Recht. Es ist im Grunde genommen die gleiche Aufgabe die Hystrix erledigt. Mit einem signifikanten Unterschied…

ES IST SYSTEMSEITIG

Jop, das habt ihr richtig gelesen. Hystrix macht seinen Job gut, hat aber nur ein Problem: Sobald wir es einsetzen haben wir nicht mehr wirklich einen Microservice. Sinn eines Microservices ist es schließlich sich autonom um seine eigenen Zuständigkeiten zu kümmern und die Robustheit eines Systems gehört eigentlich nie in die Zuständigkeit eines einzelnen Services. Statt also unsere unschuldigen Microservices mit Aufgaben zu überladen, die eigentlich gar nicht deren Job sind, geht Istio hin und kümmert sich systemweit darum, dass diese Aufgaben durchgängig erfüllt werden. Magisch, oder?

Auch die anderen drei Punkte behandeln ähnliche Situationen. Observability behandelt die Beobachtbarkeit der Kommunikationen und Abhängigkeiten untereinander, welche mit der Anzahl an Microservices exponentiell steigt und schnell unübersichtlich wird. Policy Enforcement steht für die Möglichkeit Services bestimmte Auflagen zu geben, welche diese innerhalb des Netzwerks erfüllen müssen. Service Identity und Security behandelt schließlich die eindeutige Identifizierbarkeit von Services und die Möglichkeit sichere Kommunikation auch über unsichere Kanäle zu gewährleisten.

Klingt ja sehr interessant, aber auch ein wenig zu gut um wahr zu sein. Wie kriegt Istio das Alles also unter einen Hut, ohne es durch die Applikationen erledigen zu lassen? Mittels einer in sich simplen aber (meiner Meinung nach) genialen Architektur. Sie teilt das gesamte System in die Data Plane und die Control Plane:

Istio Architektur von istio.io

In dem Schaubild ist die Control Plane ja sehr leicht wiederzufinden. Doch wo ist die Data Plane? Hier kommt die Magie ins Spiel. Die Data Plane besteht aus den Envoy-Proxies, welche sich innerhalb der Kubernetes-Pods um die bereitgestellten Services wrappen und jeglichen Traffic dieser Services behandeln. Der Envoy Proxy ist ein extrem performanter in C++ geschriebener Proxy, der diverse Funktionen rund um Discovery, Load-Balancing, Circuit-Breaker und Metriken bietet. Essentiell ermöglicht er also der Control Plane alle für die vier Kernaufgaben notwendigen Parameter zu steuern, ohne die Container oder ihre Applikationen auch nur anfassen zu müssen.

Die Control Plane wiederum kümmert sich um die tatsächliche Koordination der einzelnen Aufgaben. Der Mixer übernimmt Zugriffssteuerung und dementsprechend auch die Policy Kontrolle. Zusätzlich ist er die Einheit, welche die vom Envoy-Proxy gesendeten Signale entgegennimmt und zur Steuerung verarbeitet. Der Pilot
hingegen bietet dem User eine Schnittstelle zum Service-Mesh, um eigene Konfigurationen und Beobachtungen durchzuführen und im Mesh bekanntzugeben. Er ermöglicht eine während der Laufzeit durchführbare Konfiguration des Traffics über layer-4 und HTTP/gRCP Routingregeln. Jop, auch das habt ihr richtig gelesen -> der Traffic wird über die standardmäßigen Routingregeln gesteuert. Istio-Auth kümmert sich schließlich um die Authentifizierung über TLS und bietet somit alle Funktionen bezüglich der eindeutigen Identifizierung von Services innerhalb des Meshs.

Und das wars auch schon für heute. Zusammengefasst ermöglicht Istio also wichtige Schlüsselfunktionen innerhalb eines verteilten Systems und nimmt die Last dieser Aufgaben von unseren Microservices. Das ganze Projekt befindet sich noch in der Alpha-Phase, aber war einfach zu großartig um es für diesen Blog zu ignorieren. Auf der anderen Seite macht mich das noch mehr gespannt auf alles was noch folgen wird. Vielleicht gibt’s ja später noch ein Einrichtungstutorial von mir 😉

Danke fürs Durchlesen und viel Spaß beim Ausprobieren.

Deprecated Deprecation

JDK9 includes many exciting changes. It’s easy to overlook the minor ones, when they have to fight for the spotlight with features like the module system or the jshell. One of those features is JEP 277: Enhanced Deprecation. Yeah, i know… deprecation. Not exactly a word we like to see in our precious codebase. But necessary none the less, so here we go!

Why Deprecation?

So, before jumping right into the changes introduced with JEP 277, lets take a moment to reflect on the reasons Deprecation was introduced back in JDK2. Back then, no possibility existed to mark unsatisfactory code as such. Therefore everybody was forced to rely on their own jurisdiction regarding the usability of foreign code.

It’s easy to forget how important the information of deprecation is, especially for our current development paradigms. Not only are we notified about significant changes of modules we use, it also enables us to provide this same information to others who use our code. This is an essential communication feature, but also easily misused or ignored entirely. JEP 277 was introduced to tackle these problems and provide a solution to the rather neglecting treatment deprecation received so far.

The changes

So what exactly was changed with JEP 277? Well, the most significant changes were done to the Annotation itself. Two new attributes were introduced to enable developers to provide information about the current state of the depcrecation more precise. The first added attribute is „since“ and contains a String. It is used to indicate the age of the information itself. Authors are able to precisely document the version number, in which the Source went into deprecation for the first time. This can be helpful to pinpoint the reasons for the deprecation as well as alternatives for the deprecated source even in later versions, as they should be mentioned in the documentation of the respective version.

The second added attribute is „forRemoval“ and is depicted by a simple Bool with „false“ as it’s default. The provided information is just as simple as it is crucial. If the value is „true“, the annotated API element is marked for future removal. This means as well, that future versions *will* break code which uses this element. It is intended to emphasize the necessity of refactoring any code using those elements as well as providing authors an undisputable tool to remove unwanted elements from their code. Please take note though, that the flag only indicates *that* the deprecated element will be removed, not *why*. This was decided to prevent bloating the annotation too much and should therefore be documented in the javadoc tag.

The behaviour

Of course having those new attributes is already a nice asset, but it would be even better if they were recognised and covered by the JVM. Well, don’t fret, JEP 277 covered this as well! The biggest impact affects, as to be expected, the warning policy. The „forRemoval“-Tag introduces an entirely new type of deprecation, also requiring a heavier
handling than normal deprecation. In JEP 277 this is coined with the term „terminal deprecation“. The warning policy is affected by the deprecation state of both provider and user. Before the introduction of terminal deprecation, this of course meant that only four different states could be achieved. Terminal deprecation pushes the number of possible states up to nine. Tab 1.1 and 1.2 show the corresponding differences. As we can see, ordinary deprecation only issued a warning when the users site was not deprecated as well. Terminal deprecation on the other hand issues a warning at all possible states and got it’s own harsher formulated „terminal warning“. In order to visualize this, we will now create some sourcecode to show the difference in behaviour at compile time. First of all, we create two modules in order to simulate the integration of a foreign framework into our own code:

module Deprecated.Examples {
    exports org.normal;
    exports org.deprecated.directly;
    exports org.deprecated.indirectly;
}

module Deprecated.Changes {
    requires Deprecated.Examples;
}

Then we create a simple class to call a number of deprecated classes and methods from our second module, which itself
is not deprecated:

package jdk9.deprecated;

import org.deprecated.directly.DirectlyDeprecatedClass;
import org.deprecated.directly.DirectlyDeprecatedClassForRemoval;
import org.deprecated.directly.DirectlyDeprecatedMethods;
import org.deprecated.directly.DirectlyDeprecatedMethodsForRemoval;
import org.deprecated.indirectly.IndirectlyDeprecatedMethods;
import org.deprecated.indirectly.IndirectlyDeprecatedMethodsForRemoval;

/**
 * Shows the warnings concerning Deprecation in JDK9
 * Created by Simon on 11.05.2017.
 */
public class DeprecationTester {
    public static void main(String[] args) {
        DirectlyDeprecatedClass showsDeprecation = new DirectlyDeprecatedClass();
        DirectlyDeprecatedClassForRemoval showsDeprecationToo = new DirectlyDeprecatedClassForRemoval();
        DirectlyDeprecatedMethods directlyDeprecatedMethods = new DirectlyDeprecatedMethods();
        DirectlyDeprecatedMethodsForRemoval directlyDeprecatedMethodsForRemoval = new DirectlyDeprecatedMethodsForRemoval();
        directlyDeprecatedMethods.doDeprecatedThings();
        directlyDeprecatedMethodsForRemoval.doReallyDeprecatedThings();
        IndirectlyDeprecatedMethods indirectlyDeprecatedMethods = new IndirectlyDeprecatedMethods();
        indirectlyDeprecatedMethods.useSomethingDeprecated();
        IndirectlyDeprecatedMethodsForRemoval indirectlyDeprecatedMethodsForRemoval = new IndirectlyDeprecatedMethodsForRemoval();
        indirectlyDeprecatedMethodsForRemoval.useSomethingReallyDeprecated();
    }
}

In order to show the differences in behaviour, we copy this class and tag it as deprecated this time:

package jdk9.deprecated;

import org.deprecated.directly.DirectlyDeprecatedClass;
import org.deprecated.directly.DirectlyDeprecatedClassForRemoval;
import org.deprecated.directly.DirectlyDeprecatedMethods;
import org.deprecated.directly.DirectlyDeprecatedMethodsForRemoval;
import org.deprecated.indirectly.IndirectlyDeprecatedMethods;
import org.deprecated.indirectly.IndirectlyDeprecatedMethodsForRemoval;

/**
 * Shows the warnings concerning Deprecation shown in deprecated classes in JDK9
 * Created by Simon on 16.05.2017.
 */
@Deprecated(since = "9")
public class DeprecatedDeprecationTester {
    public static void main(String[] args) {
        DirectlyDeprecatedClass showsDeprecation = new DirectlyDeprecatedClass();
        DirectlyDeprecatedClassForRemoval showsDeprecationToo = new DirectlyDeprecatedClassForRemoval();
        DirectlyDeprecatedMethods directlyDeprecatedMethods = new DirectlyDeprecatedMethods();
        DirectlyDeprecatedMethodsForRemoval directlyDeprecatedMethodsForRemoval = new DirectlyDeprecatedMethodsForRemoval();
        directlyDeprecatedMethods.doDeprecatedThings();
        directlyDeprecatedMethodsForRemoval.doReallyDeprecatedThings();
        IndirectlyDeprecatedMethods indirectlyDeprecatedMethods = new IndirectlyDeprecatedMethods();
        indirectlyDeprecatedMethods.useSomethingDeprecated();
        IndirectlyDeprecatedMethodsForRemoval indirectlyDeprecatedMethodsForRemoval = new IndirectlyDeprecatedMethodsForRemoval();
        indirectlyDeprecatedMethodsForRemoval.useSomethingReallyDeprecated();
    }
}

As you can see, we differentiated in both those classes between deprecated classes, deprecated methods and direct/indirect deprecation. In this case indirect deprecation shows the call of a method or class, which is not deprecated itself, but uses deprecated code. This is an interesting case, as similar code could break your own calls when deprecated elements are finally removed, even without using the deprecated elements yourself. Finally we declare the used classes and methods in our other module:

package org.normal;

public class NothingDeprecated {
    public void doNothing(){
        //does nothing
    }
}
package org.deprecated.directly;

/**
 * Class annotated entirely as Deprecated, but not marked for removal
 * Created by Simon on 11.04.2017.
 */
@Deprecated(since = "9")
public class DirectlyDeprecatedClass {
    public void doDeprecatedThings() {
        //does deprecated Things
    }
}
package org.deprecated.directly;

/**
 * Class annotated entirely as Deprecated and marked for Removal
 * Created by Simon on 11.04.2017.
 */
@Deprecated(since = "9", forRemoval = true)
public class DirectlyDeprecatedClassForRemoval {
    public void doEntirelyDeprecatedThings(){
        //do something evil, which should be removed
    }
}
package org.deprecated.directly;

/**
 * Class with methods which are directly deprecated
 * Created by Simon on 11.04.2017.
 */
public class DirectlyDeprecatedMethods {
    @Deprecated(since = "9")
    public void doDeprecatedThings(){
        //does deprecated things
    }
}
package org.deprecated.directly;

/**
 * Class with deprecated methods, which are marked for removal
 * Created by Simon on 11.04.2017.
 */
public class DirectlyDeprecatedMethodsForRemoval {
    @Deprecated(since = "9", forRemoval = true)
    public void doReallyDeprecatedThings(){
        //does something evil to be removed
    }
}
package org.deprecated.indirectly;

import org.deprecated.directly.DirectlyDeprecatedMethods;

/**
 * Class with methods, which have deprecated dependencies
 * Created by Simon on 11.04.2017.
 */
public class IndirectlyDeprecatedMethods {
    public void useSomethingDeprecated(){
        DirectlyDeprecatedMethods directlyDeprecatedMethods = new DirectlyDeprecatedMethods();
        directlyDeprecatedMethods.doDeprecatedThings();
    }
}
package org.deprecated.indirectly;

import org.deprecated.directly.DirectlyDeprecatedMethodsForRemoval;

/**
 * Class with methods, which have deprecated dependencies marked for removal
 * Created by Simon on 11.04.2017.
 */
public class IndirectlyDeprecatedMethodsForRemoval {
    public void useSomethingReallyDeprecated(){
        DirectlyDeprecatedMethodsForRemoval directlyDeprecatedMethodsForRemoval = new DirectlyDeprecatedMethodsForRemoval();
        directlyDeprecatedMethodsForRemoval.doReallyDeprecatedThings();
    }
}

After this is said and done, we are set to try out the JEP 277 changes first hand. In order to do this we can first compile our two classes without any additional flags. Normally this wouldn’t show any warnings, but as we can see:

Even though we didn’t intend to get deprecation warnings, the compiler still shows three fresh warnings for the elements tagged for removal

The terminal warnings are shown without any additional configuration and independent to the state of the calling class itself. As mentioned in the warning we can get additional information by using -Xlint:deprecation as a flag, if we want to get the warnings for regular deprecation as well:

Please note, that even though we now get the regular warnings as well, they are still differentiated between [deprecation] and
[removal].

The neighbours

Something not to be forgotten is of course the javadoc tag @deprecated. Annotation and tag should always both be present.While the Annotation is used to tag the element itself for further code usage and tools, the tag provides the fineprint. This can be the reason of the deprecation itself, or alternatives to the usage of said deprecated element. Interestingly enough, the javac flag -Xlint:dep-ann considers a @deprecated tag without the corresponding annotation a mistake, while ignoring the reversed situation.

Another interesting fact is the difference between a terminal deprecation warning and a normal deprecation warning. We already saw above, that the terminal warning is a little bit harher in it’s description, but it also behaves differently. The all too popular @SuppressWarnings(„deprecation“) doesn’t supress terminal warnings! This is not to be underestimated, as it provides critical information for classes, which had their warnings supressed prior to the deprecation changes. Of course there is now a new @SuppressWarnings(„terminal“) to supress the terminal warnings. But the split between those two still requires you to go through your own legacy code and make the conscious decision of wether to refactor or to supress the new warning.

Summary

Well and that’s it for now. I still wanted to write a few words about the new tool jdeprscan, but i haven’t gotten around to try it yet, so this will probably follow as another article. So thanks for reading and till next time!

Hackathon, 18.05.2017

Heute hat endlich unser zweiter Hackathon stattgefunden. Dieses mal waren wir in einer Location außerhalb, nämlich hier. Der Raum war angenehm und für unsere Zwecke gut ausgestattet. Wir haben weiter an einer Spring-Boot-Anwendung gebastelt. Hier sind zwei Zeitraffervideos von der Veranstaltung.

Mir persönlich hat die Veranstaltung viel Spaß gebracht. Ich hoffe, im nächsten Quartal erneut einen Hackathon auf die Beine gestellt zu bekommen.

Kaffemaschine ins WLAN bringen

Wer wie ich Arduinos spannend findet und nach einem Projekt sucht, der kann ja darüber nachdenken seine Kaffeemaschine über WLAN zu steuern. Der Gedanke bei mir war, dass ich gerne morgens laufen gehe und wenn ich wieder zu Hause bin einen Kaffee trinken möchte. Oder aber auch morgens um eine bestimmte Uhrzeit von meiner Kaffeemaschine geweckt zu werden, weil dann der Kaffee schon fertig ist und man dadurch motivierter ist, aufzustehen.

Ich habe eine Tchibo-Caffisimo Compact. Diese hat 3 Knöpfe in einem Frontpanel, einen für Espresso, einen für Kaffee-Crema und einen für Filterkaffee. Ich hatte den Gedanken, die komplette Maschine auseinander zu schrauben, da ich gerne sowohl meine Anschlüsse als auch meinen Microcontroller in dem Gerät untergebracht bekommen hätte. Leider war ich nach 2 Stunden schrauben nicht in der Lage, das Gerät weiter auseinanderzunehmen. Ich hatte es geschafft den Unterboden zu öffnen, aber an die relevanten Teile war aus meiner Sicht kein rankommen.

Hier links im Bild sieht man jedoch die drei bereits erwähnten Schalter. Mein weiteres Vorgehen bestand dann darin, dass ich die „Gummikappe“ die die eigentlichen drei Schalter überdeckt, herausgezogen habe. Darunter waren dann drei einfache Schalter mit jeweils 4 Kontakten.

Da manche Kaffeemaschinen ihre Bedienelemente unter Netzspannung haben, habe ich nachgemessen, die Spannung lag bei 5V. Als nächstes habe ich testweise die Kontakte der Schalter der Reihe nach überbrückt. Dabei kam heraus, dass ich das Kochen von Kaffee durch das Überbrücken des unteren linken und oberen rechten Kontaktes auslösen kann. Daraufhin habe ich dünne Drähte genommen und an diese Kontakte angelötet. Um die Kontakte schalten zu können, habe ich mir folgendes Relais-Board gekauft: das Relaisboard Dazu habe ich mir folgenden Arduino-Klon mit integriertem WLAN gekauft: Arduino-Klon. Da es sich um einen nicht richtig lizensierten Klon handelt, muss man einen eigenen Treiber installieren, wenn ich alles richtig verstanden habe, dann deswegen, weil das Board tatsächlich keine Lizenz für USB hat. Link zu den Treibern beim Hersteller. Dummerweise hat der Treiber vom Hersteller es geschafft, meinen Mac zum Absturz zu bringen, etwas was mir tatsächlich vorher noch nie passiert war. Eine Lösung für dieses Problem habe ich hier gefunden. Anschließend habe ich einfach den Beispielcode genommen und minimal modifiziert:

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>

const char* ssid = "meine WLAN-SSID";
const char* password = "mein WLAN-Passwort";
const int relaisPin1 = 5;

ESP8266WebServer server(80);

const int led = 13;

void handleRoot() {
  digitalWrite(led, 1);
  server.send(200, "text/plain", "hello from esp8266!");
  digitalWrite(led, 0);
}

void handleNotFound(){
  digitalWrite(led, 1);
  String message = "File Not Found\n\n";
  message += "URI: ";
  message += server.uri();
  message += "\nMethod: ";
  message += (server.method() == HTTP_GET)?"GET":"POST";
  message += "\nArguments: ";
  message += server.args();
  message += "\n";
  for (uint8_t i=0; i<server.args(); i++){
    message += " " + server.argName(i) + ": " + server.arg(i) + "\n";
  }
  server.send(404, "text/plain", message);
  digitalWrite(led, 0);
}

void setup(void){
  pinMode(led, OUTPUT);
  pinMode(relaisPin1, OUTPUT);
  digitalWrite(led, 0);
  Serial.begin(115200);
  WiFi.begin(ssid, password);
  Serial.println("");

  // Wait for connection
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.print("Connected to ");
  Serial.println(ssid);
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());

  if (MDNS.begin("esp8266")) {
    Serial.println("MDNS responder started");
  }

  server.on("/", handleRoot);

  server.on("/coffee", [](){
    digitalWrite(relaisPin1, HIGH);
    delay(1000);
    digitalWrite(relaisPin1, LOW);   
    server.send(200, "text/plain", "cooking coffee");
  });

  server.onNotFound(handleNotFound);

  server.begin();
  Serial.println("HTTP server started");
}

void loop(void){
  server.handleClient();
}

Das Ergebnis kann man sich in diesem Video ansehen:

Was ich effektiv mache ist in meinem Browser die IP des Microcontrollers aufzurufen. Wenn mein Code funktioniert, dann bekomme ich eine Seite in meinem Browser, die „hello from esp8266!“ ausgibt. Wenn ich an die URL ein „/coffee“ anhänge, kocht meine Maschine Kaffee. Nun sieht man aber in dem Video, dass jetzt „lose Drähte“ vorne aus meiner Kaffeemaschine raushängen und auch sonst sieht das eher unbenutzbar aus. Meine weitere Optimierung bestand darin, in die silberne Plastikabdeckung der Taster von seitlich rechts aus ein Loch zu bohren, durch das ich die Drähte führen konnte. Das ganze sah so ungefähr so aus wie hier rechts. Insgesamt ein lustiges Projekt, sehr befriedigend, allerdings nicht zu empfehlen, wenn man das Projekt nicht an einem Tag fertigstellen kann und keine zwei Kaffeemaschinen hat, da das bedeuten kann, dass man am zweiten Tag ohne Kaffee an dem Projekt arbeiten muss.