by Henrik Triem | Oct 23, 2019 | NETWAYS
Name: Henrik Triem
Alter: 24 Jahre
Position bei NETWAYS: Junior Developer
Bei NETWAYS seit: August 2018
Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?
Ich habe das große Vergnügen, mich in C++ und Icinga Core reinzufuchsen. Von den Grundlagen der Softwareentwicklung bis hin zu ausgeklügelten Feinheiten des Icinga-Codes, meine Hauptaufgabe ist es momentan, mich zu einem Icingaexperten zu machen. Dazu werden von mir Issues bearbeitet, ich sauge die Konzepte und Ideen auf, die meine Kollegen in den Code eingearbeitet haben, und versuche mich Stück für Stück mehr einzubringen.
An welchen Projekten arbeitest Du gerade?
Momentan versuche ich verschiedenste Konzepte von Icinga zu verinnerlichen; darunter die DSL oder auch die Verwendung von TLS in unserem Code. Außerdem steht bald wieder ein neuer Release an!
Welche größeren oder besonders interessanten Projekte stehen zukünftig an?
Eines der größeren Projekte in näherer Zeit wird es sein, den Icinga Core auf C++11-Standard zu heben. Generell ist die Modernisierung ein Prozess, der niemals abgeschlossen ist, und mich brennend interessiert.
Was macht Dir an Deiner Arbeit am meisten Spaß?
Die Freiheiten, die ich bekomme, um mich in Themengebiete reinzuarbeiten, Issues und Probleme zu bewältigen, und einen aktiven Aufbereitungsprozess zu haben. Als Programmierer freut man sich eh über jede kleine Hürde, die genommen wird; sogesehen sind in einer Debugging Session tausende kleine Freudenmomente versteckt.
Was machst Du, wenn Du mal nicht bei NETWAYS bist?
Wenn ich mich mal zuhause rumtreiben sollte, widme ich mich dort meinem Klavier und meiner Gitarre. Meistens bin ich aber in allen Ecken und Enden Deutschlands meinen Schabernack treibend zu finden…
Wie geht es in Zukunft bei Dir weiter?
Erstmal steht der (hoffentlich gute!) Abschluss meiner Ausbildung als Fachinformatiker in Anwendungsentwicklung an; danach hoffe ich, dass ich mich weiterhin gut und in vielerlei Hinsicht gebildeter und wertvoller in die Firma einbringen kann.
Henrik Triem
Junior Developer
Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.
by Henrik Triem | Aug 22, 2019 | Datenbanken, Design, Development, HTML / CSS, PHP
Man bekommt nicht immer das, was man will… außer, man ist bei NETWAYS Azubi!
Mein erstes Jahr bei NETWAYS ist fast vorüber, und meine jugendlichen Ambitionen haben den Wunsch in mir erweckt, mit den beiden anderen Dev-Azubis meines Jahres, Loei und Niko, ein eigenes Projekt zu übernehmen, um unsere erlernten Fertigkeiten zu prüfen, eine Übersicht davon zu bekommen, auf welchem Stand wir alle sind, den ein oder anderen Trick voneinander aufzuschnappen und eigenverantwortlich und kooperativ ein Projekt zu vervollständigen. Und alles, was es gebraucht hat, um diesen Wunsch zu erfüllen, war diese Idee zu pitchen und klar und deutlich zu vermitteln, warum dieses Interesse besteht, und was wir uns davon erhoffen. Meine Vorgesetzten scheinen von der Idee zumindest angetan genug gewesen zu sein, dass wir drei Wochen eingeräumt bekommen haben, um uns um dieses Projekt zu kümmern. Danke, NETWAYS!
Die Aufgabe klingt einfach, hat es aber doch durchaus in sich – aus Berichten in Icinga sollen PDFs generiert werden. Die Funktionalität ist schon vorhanden – unsere Aufgabe ist es, den Benutzern mehr Features zur Verfügung zu stellen, damit man eigene Anpassungen an dem Aussehen der PDFs vornehmen kann. Das Schöne an dieser Aufgabe ist die Breite der Elemente und Bereiche, welche eine Rolle dabei spielen. Icingaweb, PHP, HTML, CSS, Google Chrome… es ist in gewisser Art und Weise eine große Reise in das Unbekannte, und natürlich können wir alle drei uns nicht sicher sein, welche Probleme und Hürden sich uns in den Weg stellen werden, und wie die zündenen Ideen kommen, die uns helfen, diese Hürden zu überwinden.
Boo
Much better
Und zündende Ideen gab’ es bereits! Ein Beispiel: Google Chrome baut sich aus HTML-Code die PDFs zusammen, lässt sich es aber nicht nehmen, automatisch generierte Header und Footer anzufügen, mit Seitenzahl und Datum. Das ist natürlich ein Element, welches wir gerne unter Kontrolle hätten! Der erste Hack, mit dem ich mich über diese Hürde bewegt habe, ist ein CSS-Styleelement an den übergeben HTML-Code anzufügen. Das ist in seinem momentanen Zustand natürlich noch etwas unschön gelöst, wenn einfach nur der HTML-Code um ein fest eingebautes Codeelement erweitert wird, aber wir haben einen Einstiegspunkt, einen Ansatz, mit der wir weiterbauen und -basteln können.
Scheue Dich vor Fragen nicht!
Auch wenn der Kerngedanke dieses Projekts natürlich daraus besteht, dass wir uns selbst beweisen, spricht natürlich Nichts dagegen, bei Fragen, die aufkommen, einen der zahlreichen Experten die NETWAYS hat zu involvieren. Was Benutzeroberflächen angeht, ist bei uns UX-Designer Florian der Ansprechpartner Nummer 1. Wir haben uns zusammengesetzt und konnten ihm live beim Bauen eines Mockups in Sketch zusehen. Eine Gelegenheit, durch die großen Augen, die wir gemacht haben, auch etwas über grundlegende Designansätze in Icingaweb zu lernen, und Grundsätze bezüglich Design. Mit diesem Wissen können wir erstmal diesen Pfad weiter selbst beschreiten, aber natürlich werden wir viel Rücksprache führen. Nur weil man bisher nicht dazu kam, sich extensive Kenntnisse in einem Bereich selbst anzueignen, heißt das nicht, dass man dieses Wissen, wenn es einem zur Verfügung steht, nicht nutzen kann. Und immer schön dran denken, selbst den Fundus an Talenten zu erweitern.
A mockup of things to come…
Kooperatives Kodieren
Einer der in meiner Einleitung angesprochenen Tricks, den ich einfach für neat halte, und sehr dem Spirit dieses Projektes entspricht, ist die Möglichkeit in git Co-Authoren einzutragen. Dafür muss man in der commit message einfach
Co-authored-by: Name <e-mail>
angeben, und git verlinkt automatisch zwei Autoren für diesen commit. In diesem Fall meine beiden Kollegen bei diesem Projekt. Gute Arbeit, Jungs!
Da kann man ruhig mal klatschen! 👏
Willst Du uns vielleicht nächstes Jahr bei dem nächsten Entwicklungsprojekt behilflich sein? Dann raus mit Deiner Bewerbung an NETWAYS! Wir freuen uns schon auf dich!
Henrik Triem
Junior Developer
Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.
by Henrik Triem | Jun 6, 2019 | Network, Security
Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.
Warum brauchen wir TLS?
TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?
Eine Beispielverbindung:
1. ClientHello
Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.
2. ServerHello & Certificate & ServerKeyExchange
Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.
3. ClientKeyExchange
Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.
Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.
4. ChangeCipherSpec
Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.
Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.
Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.
Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.
Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.
https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.
Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.
Henrik Triem
Junior Developer
Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.
by Henrik Triem | Mar 7, 2019 | Development, Hardware
Um meine neuerworbenen Kenntnisse in C++ zu vertiefen, habe ich netterweise etwas äußerst Interessantes auf den Tisch gestellt bekommen. Einen kleinen Karton mit mehreren Elektronikbauteilen, noch in ihren Antistatikbeuteln. (Meine Vorfreude steigt ins Unermessliche.)
Worum geht’s?
TinkerForge ist ein mittelständisches Unternehmen aus Ostwestfalen-Lippe, welches Mikrocontrollerbausteine herstellt, die sogenannten Bricks. Die Idee zu diesen Bricks hatten die beiden Gründer Bastian Nordmeyer und Olaf Lüke, nachdem sie – auf der Suche nach Mikrokontrollermodulen für autonome Fußballroboter – keine entsprechenden offenen, mit verschiedenen Programmiersprachen ansteuerbaren Bauteile gefunden haben. Was 2011 noch mit einer kleinen Produktlinie begann, ist nun ein extensiver Katalog an Controllern (
Bricks) und Modulen (
Bricklets), die sich in zahlreichen Programmiersprachen ansteuern lassen, und sich durch ihre modulare Bauweise schier endlos verknüpfen lassen.
Neben der Option, sich seine Bricks selbst zusammenzustellen, vertreibt Tinkerforge verschiedene
Kits – Komplettpakete für verschiedene Anwendungsmöglichkeiten.
Eines dieser Kits – die
Tischwetterstation (für
114,99 €) habe ich zum Austoben bekommen, dazu gab es noch einen WIFI Master Extension Brick (für 29,99€).
In diesem Blogpost wird es um das “Unboxing”, den Zusammenbau, die erste Einrichtung und Codebeispiele von Tinkerforge selbst gehen.
Was haben wir denn da?
Hierbei handelt es sich um den
Master Brick, Version 2.1. Man kann sich diesen Brick wie die zentrale Verteilerstelle vorstellen. Er hat eine USB-Schnittstelle und hat – neben den stapelbaren Anschlüssen für andere Bricks (Master Extensions, siehe Wifi Extension!) – hat er vier Anschlüsse für Bricklets (siehe Air Quality Bricklet!), und kümmert sich um die Kommunikation zwischen den einzelnen Modulen. Dort wird auch die Verbindung zu einer Recheneinheit hergestellt, die verschiedene Formen annehmen kann, worauf ich später noch kurz eingehen werde. Außerdem ist der Master Brick mit zwei kleinen Knöpfchen an der Seite des USB-Anschlusses ausgestattet, ein Reset-Knopf und ein Erase-Knopf.
Dies ist die
WIFI Master Extension, Version 2.0. Dieser Brick kann auf den Master draufgesteckt werden – der Formfaktor ist mit 4×4 cm gleich, euch fallen auch garantiert die Anschlüsse an den Seiten des Bricks auf. Mit diesen Anschlüssen lassen sich mehrere, verschiedenste Kombinationen von Bricks aufeinander stapeln, die das ganze System um zahlreiche Funktionen erweitern können. In diesem Fall, bei der WIFI Master Extension 2.0 handelt es sich um ein Kommunikationsmodul, mit dessen Hilfe sich der Master Brick drahtlos steuern ließe. Bisher hat dieser Brick aber noch nicht die ausreichende Liebe von mir erfahren – da die Wetterstation (noch?) nicht ohne Rechenpower von außen funktioniert, und per USB über den Master Brick mit Strom versorgt werden muss – dementsprechend die Kommunikation bisher größtenteils auch über dieses USB-Kabel lief.
Na, fällt euch schon etwas auf? Dieser Brick ist kein Brick, sondern ein Bricklet, der Formfaktor ist auch deutlich kleiner, mit 2,5×2 cm – es fehlen auch die gerade angesprochenen Anschlüsse zum Stapeln. Dieses kleine Bauteil ist der
Air Quality Bricklet, ein interessantes Bauteil, welches mehrere Sensoren an Bord hat. Das Herzstück ist der
Indoor Air Quality (kurz IAQ)-Sensor, welcher “flüchtige organische Verbindungen” (Volatile Organic Components, kurz VOC) misst. Diese Messungen werden mit den Messungen der ebenso vorhanden Luftdruck-, Luftfeuchte- und Temperatursensoren kombiniert, um den IAQ-Indexwert zu bestimmen. Laut TinkerForge braucht es rund 28 Tage Durchlaufzeit für die vollständige Kalibrierung dieses Moduls, ansonsten gilt der IAQ-Indexwert als unzuverlässig. Soviel Zeit habe ich dem Bricklet noch nicht gegeben, aber das kommt auch noch. Angeschlossen wird dieses Sensorpaket – per in dem Tischwetterstationskit enthaltenen 10-Pol- auf 7-Pol-Kabel – an den Master Brick. Insgesamt ist dieses kleine, aber feine Bauteil das, was diese Tischwetterstation zu einer Wetterstation macht.
Ein LCD-Bildschirm! Auf irgendwas muss ich ja schauen können, wenn ich es schon explizit vermeide, aus dem Fenster zu schauen, um zu sehen, wie das Wetter so ist.
Spaß beiseite, dieses Bauteil ist für mich wohl am Interessantesten aus dem ganzen Kit, denn die Möglichkeiten mit einem 2,8″ großem Display mit 128×64 Pixel wären schon unbegrenzt genug – dann hat das wunderbare Ding auch noch einen resistiven Touchscreen! Ich bin sehr gespannt drauf, was für kreative Ideen Ihr (und ich) mit sowas haben könntet (und wie weit die sich von der Grundidee einer Wetterstation entfernen). Wetterstationsschach, anyone?! Das Display wird genauso wie der Air Quality Bricklet über ein 10-Pol- auf 7-Pol-Kabel mit dem Master Brick verbunden.
Wo wir bei Kabeln sind – in dem Paket waren die zwei benötigten 10-Pol- auf 7-Pol-Kabel dabei, und das USB-Kabel, welches zur Stromversorgung und Kommunikation der Recheneinheit mit der Wetterstation dient. Außerdem war auch noch eine Schutzhülle aus gelasertem Plastik, und jede Menge Schrauben dabei. Alles, was das Bastlerherz begehert. Dann öffnen wir all die schönen Dinge mal!
Hardware braucht Software
Nach dem Auspacken der Bauteile (mit gebührendem Respekt) habe ich – vor dem großen Zusammenschrauben – die Bricks testen und einrichten wollen. Dazu bietet TinkerForge zwei Programme an, den Brick Deamon und den Brick Viewer.
Heruntergeladen, Master Brick per USB angeschlossen… es wird nichts erkannt. Hm.
Der Brick Viewer zeigt kein neues Modul an. Nach einigem Grübeln kam’ ich auf die Idee, den Master Brick mit einem
RED Brick, den wir (inklusive einiger anderer Module) in der Firma haben, zu verbinden und den (eingerichteten) RED Brick mit meinem Rechner zu verbinden. Damit konnte ich auch den Master Brick im Brick Viewer finden. Den RED Brick abmontiert und den Master Brick wieder mit USB mit dem Rechner verbunden, siehe da, wir haben eine Verbindung. Die anderen Module u. Bricklets ließen sich ganz einfach durch Verbinden mit dem Master Brick ansteuern und die Updates funktionierten auch sehr einfach; allerhöchstens der Prozess den Master Brick auf den neuesten Stand zu bringen ist ein wenig komplizierter als nur auf den Updateknopf im Brick Viewer zu drücken; man muss zuerst den Erase-Knopf auf der Rückseite des Master Bricks gedrückt halten, den Reset-Knopf betätigen und loslassen, und dann den Erase-Knopf ebenso loslassen. Dies versetzt den Master Brick in den Bootloadermodus, dadurch lässt sich dann die neue Firmware über eine serielle Schnittstelle (in meinem Fall USB) aufspielen.
Der Brick Viewer ist ein kleines GUI-Tool, mit dem sich die einzelnen Bricks und Module updaten, testen und einrichten lassen.
Jeder Brick hat seinen Eintrag und seinen Reiter, eine UID (wichtig!), eine Position und eine Firmwareversion. Hier kann man sehr unkompliziert beispielweise die WIFI Extension einrichten, und die Kommunikation über diese Verbindung ablaufen lassen.
Hier sieht man den Reiter für den Air Quality Bricklet. Die Werte werden sekündlich geupdatet, und man kann ohne eigenes Zutun schauen, ob die Sensoren das tun, was sie sollen, oder der grundlegende Aufbau der Wetterstation stimmt. Der Brick Viewer sollte für alle Experimente die erste Anlaufstelle sein, da man hier überprüfen kann, ob alles seine “Arbeit” so erledigt, wie es das soll.
Der
Brick Daemon ist ein zentrales Stück Software bei der Ansteuerung der einzelnen Bricks und Bricklets; der Brick Daemon sorgt dafür, dass – egal, welche von den unterstützen Programmiersprachen (
eine lange Liste) man für eigene Programme verwenden sollte – die Kommunikation auf TCP/IP-Basis abläuft, sodass mit den von TinkerForge bereitgestellten APIs sich Bindings ohne Abhängigkeiten erstellen lassen. Seinen Dienst erledigt der Brick Daemon vergleichweise still im Hintergrund, loggt dabei aber auch jede Menge Informationen, Warnungen und Fehler – ein weiteres praktisches Feature, bei dem einem von TinkerForge einiges an Arbeit abgenommen wurde.
Nachdem ich alle Bricks getestet habe, und die Station zusammengebaut und -geschraubt habe, habe ich mich gleich auf die ebenso von TinkerForge bereitgestellte
Demoanwendung gestürzt, und auch da – es wäre schwer, mir das Leben noch einfacher zu machen. Die Demo-Anwendung ist in Python geschrieben, und bietet einem eine grundlegende Anzeige, die die Wetterstation allerdings schon voll funktionstüchtig macht. Der Quellcode der Anwendung bietet sogar sehr einfache Optionen, sich seine eigenen Reiter zusammenzustellen – mit eigenen Icons, Funktionen, sogar Bilder lassen sich per Python Imaging Library zur geeigneten Ausgabe auf dem LCD-Bildschirm konvertieren und ausgeben.
Hübsch, oder? Und das ist alles auf der Website von TinkerForge frei erhältlich – also, der Quellcode, aber auch die Schaltpläne der einzelnen Bricks, für die Elektrobauteiltüftler unter euch.
Ich denke, das sollte erstmal als grobe Übersicht, was für ein Projekt ich auf dem Tisch habe, reichen.
Erster Eindruck?
Mein erster Eindruck, bzw. Gedanke, den ich hatte, als ich die Bauteile ausgepackt habe, war: “Jetzt nochmal vierzehn sein, und so etwas unter dem Baum stehen haben. Ich wäre verliebt gewesen.” Nicht, dass das zehn Jahre später bei mir gänzlich anders aussieht. Das, was ich bisher alles mit dieser Wetterstation gemacht habe, und was sich wohl noch machen lässt… eine Plethora an Möglichkeiten, die sich einem öffnet. Die Bauteile, ihre modulare Bauweise, all der Quellcode und die Programme, die einem mitgegeben werden, beziehungsweise welche man auf der TinkerForge Website findet, sind sehr extensiv, und gerade deswegen würde ich sagen, es ist absolut super geeignet für junge, neugierige Bastler und Tüftler mit einer Leidenschaft für das Programmieren und Elektrobauteile.
Das scheint mir aber auch wirklich nicht das Anwendungsgebiet dieser Wetterstation zu sein, nein. Die Bauteile, das Set, all diese Dinge sind ganz klar auf Tüftler ausgelegt, und die wirklich sehr hohe Einsteigerfreudlichkeit macht dieses Kit definitiv zu einer Empfehlung für junge Leute ab vierzehn, die mal gerne ihre grundlegenden Programmierfertigkeiten mit einer greifbaren Anwendung verknüpfen wollen. Der Kreativität ist dank des Screens ohnehin schon keine Grenzen gesetzt; die modulare Bauweise würde auch noch viele Erweiterungen für diese Wetterstation unterstützen.
Also, fertigt schonmal die Wunschzettel an, denn nach Weihnachten ist vor Weihnachten.
Im zweiten Teil dieser Blogposts werde ich dann die ersten selbstgeschrieben Anwendungen von mir vorstellen, auf die APIs eingehen, und weitere Ideen besprechen, die ich bislang schon hatte, und auch noch haben werde.
Henrik Triem
Junior Developer
Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.
by Henrik Triem | Nov 15, 2018 | Development, English, GitLab, NETWAYS
(…and I’m only 13 years late to the party…)
First of all, I have a confession to make. I’m code shy. At least that’s what I thought I was.
One of the fresh-faced young trainees this year here at NETWAYS, I’m not entirely “new” to the scene. Having gone to university (with varied success) I never was bestowed with the confidence to actually contribute to anything. In terms of feedback, my lecturers and I only looked at what I was doing wrong – yes, admittedly, to get me to stop what I was doing wrong, but approaching code like this made me feel like I was always doing something wrong.
Again, admittedly, I probably was always doing something wrong, but I felt like I shouldn’t contribute, I mustn’t contribute, the only thing I would add to an open source project would be bugs, I would mess things up more than I would be helpful to anybody. I’ve written some small stuff for myself at home, but.. why would anybody rely on my code?
It was an awful feeling. So I never did contribute. And that’s how I became code shy.
Three months into my stint at NETWAYS, and it all changed massively. Apart from my wonderful colleagues, git helped in a big way to give me more confidence, to be more active in my participation, to instill a kind of pride in my work I haven’t felt before – to stop worrying and love my code.
So – why write the millionth paragraph about git?
This won’t be a technical introduction, but rather a little recollection of my thoughts and emotions while getting introduced to git and using it at work – because my mind has been thoroughly blown.
What’s git?
Well, let’s take a look at good ol’ Wikipedia:
Git () is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people.
Version-control? Now, what’s that supposed to mean? Is that like back in the days when I sent my source code files to my professor via mail, so he could check over them and see if I did my stuff?
Well, in a way, that could be some sort of version control system as well – just not a very automated and effective one. Version control is about the general management of files, code, data – it keeps track of changes, who did what, when (and if you’re lucky, you’ll even find a hint or two explaining why), and it allows for reversion of changes and modifications people have made.
My ears perked up when I heard this.
I can go around and mess things up and nobody would get mad at me? I won’t break stuff from the get go? I was amazed.
But how does git do it?
At work we have remote repositories hosted on GitLab, from which I could pull all of the files of the project onto my local machine. So now I have my own copy of the project, in which I could move, delete, add or modify files to my liking – and I wouldn’t break anything doing so, because the remote repository on GitLab would be completely unchanged.
In a way, it’s a sandbox for me, where I can go ahead and code, take care of issues, fix bugs, or add features, test them – until I feel safe to share the work I’ve done with other people. You can see how that is a comforting feeling to have – you can code without worries.
So – what happens behind the scenes?
Git takes snapshots of my work. A snapshot is the way git keeps track of all of the files belonging to a project. Git will checksum them, generate a SHA-1 hash. These hashes are the way git knows about the changes to the code inside the files. After I’ve staged my modified files, I can commit the changes I’ve made. Committing will checksum all of the project directories and store them in the repository – and it will store a pointer to the commit that came before it. This is awesome! So now I can have multiple points to revert the project back to, just in case. But… how would I go about doing that?
Well, let’s talk about branches. Branches are pointers to these commits, the default one being the master branch. There is a master branch on my local machine as well as on GitLab – which made me immediately nervous again. But luckily, I can just branch off of my local master, give it a meaningful name, and even push and store the commits belonging to that branch to GitLab, with the master being untouched. Again, another safe environment for me to go about my work, be more assertive in sharing it, all in a peaceful state of mind.
So – thanks to git, I feel safe in being much more creative and independent when going about contributing to our projects here at NETWAYS – and thanks to the awesome work environment here, I do have space and time to try to add to these projects in a constructive way. My colleagues can look at my code, give me tips and hints, and neither them nor me have to worry about me being a nuisance messing things up.
But what if I’ve finally fixed a bug, or added an awesome feature to one of our projects? Then it’s time to make a merge request. On GitLab, I pick a branch of mine, write a little bit about the new functions or which bugs I (hopefully) fixed, and request for these changes to be added into the master. From there, my fate lies in the hands of the project maintainers…
A successful merge request might just be the greatest feeling of all.
I know that there are a million new ways I could break things if I use git wrongly. So, getting good at git is something I must and will learn at NETWAYS. And – bursting with pride and with a newfound confidence – I look forward to learning more every day.
Henrik Triem
Junior Developer
Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.
