Tracking tasks with Todoist

As the name suggests Todoist is an app for tracking todos. I’ve been using it for the past couple of months during which it has become a daily companion in my quest for getting things done without forgetting half of my stuff (which – if you know me – is a common occurrence).

The basic feature set is quite straight-forward: The app lets you create tasks which by default end up in the “Inbox”. Todoist has native apps for macOS, Windows, iOS and Android. There’s also a web client in case you need to update your tasks on-the-go. For me personally the integration with Amazon Echo is particularly useful. Adding a new task is as simple as saying “Alexa, add a task…”.

Once you’ve created a task you can decide to assign your tasks to a project (e.g. “Work”, “Personal”, etc.) either right away or later on when you have a few minutes to spare. Each task can also be tagged to make it easier to find groups of specific tasks. For example I have two tags “LowEnergy” and “HighEnergy” so I can later on find all tasks which are either easy or hard to do. Tasks can be set to re-occur at specific intervals which range in complexity from “daily” to “every last friday”.

The mobile app supports location-based reminders. I have a recurring task “Get cash from the ATM” which the app dutifully reminds me about when I pass the ATM on my way to work.

I wouldn’t go so far as to put Todoist in the “life saver” category, however it has definitely become an integral part of my daily workflow. Consider giving it a try… even though unfortunately it isn’t entirely free.

 

 

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Ruby Applikationen testen mit RSpec und WebMock

Das Testen von Software begleitet mich von Projekt zu Projekt. Bei bisherigen Entwicklungen habe ich immer wieder auf RSpec zurück gegriffen, ein tool zum testen von Ruby Applikationen. Es zeichnet sich durch eine relativ einfache Handhabung aus und eine Ausdrucksweise die an die menschliche Sprache angelehnt ist. Auch wenn nicht jeder mögliche einzutretende Fall getestet werden kann, tests geben Entwicklern Sicherheit wenn Änderungen am Code vorgenommen werden.

WebMock

WebMock ist eine Library die es einem ermöglich HTTP requests auszudrücken und Erwartungen an diese zu setzen. In Verbindung mit RSpec lässt sich WebMock verwenden um eine Ruby Anwendung zu testen die HTTP Requests ausführt, beispielsweise an eine API. Oft sind diese Requests nicht starr sondern werden dynamisch anhand von Parametern zusammen gesetzt. WebMock/RSpec hilft dabei unterschiedliche Fälle zu simulieren, Erwartungen zu definieren und diese mit zu prüfen.

WebMock ist als Gem verfügbar, die Installation ist daher relativ einfach:

user@localhost ~ $ gem install webmock

Als Beispiel verwende ich eine sehr simple Ruby Klasse. Deren einzige Methode ‘request’ sendet einen GET request an die URL ‘https://wtfismyip.com’. Abhängig vom Parameter ‘option’ wird die IP entweder in Textform oder als JSON abgefragt:

require 'net/http'
require 'uri'

class ApiCaller
  def self.request(option)
    uri = URI.parse("https://wtfismyip.com/#{option}")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri.request_uri)
    http.request(request)
  end
end

Mein Test beinhaltet den Aufruf der ‘request’ Methode. Der HTTP request wird simuliert und die Erwartung das ein Request an eine bestimmte URL stattfinden soll wird auch definiert.

require 'api_caller'
require 'webmock/rspec'

describe ApiCaller do
  describe '.request' do
    context 'given json parameter' do
      it 'requests json url' do
        stub_request(:get, 'https://wtfismyip.com/json')
        expect(ApiCaller.request('json')).
          to have_requested(:get, 'https://wtfismyip.com/json').once
      end
    end

    context 'given text parameter' do
      it 'requests text url' do
        stub_request(:get, 'https://wtfismyip.com/text')
        expect(ApiCaller.request('text')).
          to have_requested(:get, 'https://wtfismyip.com/text').once
      end
    end
  end
end

Beim testen sieht das nun folgendermaßen aus:

user@localhost ~ $ rspec --format documentation

ApiCaller
  .request
    given json parameter
      requests json url
    given text parameter
      requests text url

Finished in 0.00557 seconds (files took 0.37426 seconds to load)
2 examples, 0 failures
Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Icinga 2 – Multi-Zonen Notifications

Komplexe Monitoring Umgebungen mit Icinga 2 kennt man ja schon und auch was sich alles mit den Satelliten und zus. Zonen-Mastern anstellen lässt. Aber wisst ihr auch, dass sich gezielte Benachrichtigungen für einzelne Zonen definieren lassen? Die meisten nutzen wahrscheinlich schlicht nur die Haupt/Master Zone für Notifications; aber gehen wir doch von einem nicht unüblichen Beispiel aus : Der externen Überwachung des eigenen Monitorings.

Wir wollen, dass der externer Satellit uns autark kontaktiert sobald das Monitoring ausfällt und im Sinne des Directors, ebenso wenig eine manuell Konfiguration pflegen. Jetzt muss er die Benachrichtigung nur irgend wie zu uns bekommen. Das Wissen über die Objekte sollte bei solchen Setups vorhanden sein, daher werde ich keine Screens oder Config-Auszüge einfügen, sondern nur das Vorgehen beschreiben.

Wie einfach das Ganze mit Zonen-Verzeichnissen und einem Parameter realisiert werden kann, zeigt sich wie folgt. Wir generieren das entsprechende Notification-Command für den Satelliten und stellen sicher, das er es, sowie die betreffenden Kontakte, in seiner Zone finden kann. Anschließend folgt auch schon das Notification Objekt, welches a.) einfach mit in das Zonen-Verzeichnis des Satelliten geschoben, oder b.) global um den Parameter “zone” erweitert wird. Und schon kann es los gehen.

All das lässt sich übrigens auch wunderbar in einem NWS Satelliten abbilden. Probiert es einfach mal aus.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

WLAN in deutschen ICEs

WIFIinICE

WLAN im Zug

Seit Anfang diesen Jahres wurde die Angebotspalette in den deutschen ICE Zügen um ein kostenloses WLAN in allen Klassen erweitert. Das kommt den viel reisenden Kollegen von Netways zu gute, welche oft im Zug unterwegs sind. Sei es jetzt unser Consulting Team, der Vertrieb auf dem Weg zum Kundentermin oder unsere Event Abteilung unterwegs zum nächsten Highlight.

Wir wollen das Ganze aber mal etwas genauer unter die Lupe nehmen und schauen, warum es besser ist als ein Hotspot per Handy oder Tablet mit seinem eigenen Mobil-Provider. Hintergrund ist die Technik, welche mit dem Partner Icomera aus Schweden zum Einsatz kommt. Sie koppelt sich parallel zu den 3 großen Anbietern (Telekom, Vodafone, Telefónica) um eine stabile und dauerhafte Verbindung herzustellen und zu gewährleisten. Damit werden Unterbrechungen auf ein Minimum reduziert und treten meist nur in langen Tunnelfahrten auf. Man bleibt aber verbunden und kann im Anschluss sofort weiter surfen.

Zu erwähnen ist noch ein Datenvolumen von 200 MB pro Tag in der 2. Klasse. Ist das Volumen aufgebraucht, wird die Geschwindigkeit reduziert, damit alle Passagiere eine gleichbleibenden Qualität nutzen können. Die Geschwindigkeit nach der Drosselung ist aber noch höher als man sie von Mobilanbietern kennt. Jedoch sollten 200 MB in den meisten Fällen pro Fahrt für eine normale Nutzung ausreichen. Es ist daher zu empfehlen, die WLAN Verbindung als ‘getaktet’ zu markieren um Hintergrundaktivitäten seiner Geräte zu mindern. Unnötige Downloads, Updates oder Streams sollten ebenfalls vermieden werden.

Werfen wir noch einen Blick auf die Sicherheit. Dabei kommen viele moderne Umsetzungen und bekannte Technologien wie z.B. die Client Isolation zum Einsatz. Jedoch ist das ganze immer noch ein HotSpot Angebot und ein Abfangen von Informationen kann nicht grundsätzlich ausgeschlossen werden. Nutzern mit sensiblen Daten wird daher die Verwendung einer VPN Verbindung und das surfen per HTTPS empfohlen.

Als Schlusswort kann ich die Nutzung nur empfehlen und begrüße das neue WLAN in den ICEs. Da ich selbst jede Woche sehr oft 5-6 Stunden pro Fahrt unterwegs bin, kann ich so mein Büro mitnehmen und die Zeit sinnvoll nutzen.

Bei weiterem Interesse, kann man sich auf den Portalen der Deutschen Bahn informieren (hier und hier)

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Monitoring Plugins in Go

Auf Twitter hat Jan Schaumann vor Kurzem begonnen eine Liste aufzustellen mit Dingen, die jeder Sysadmin in seinem Leben schon mindestens ein mal getan hat. Darunter zählen Sachen wie einen Parser für den ifconfig Befehl zu schreiben oder unvollständige Regexes für IP Adressen zu basteln. Beim Durchgehen dieser Liste habe ich mich immer wieder selbst ertappt. Es ist erschreckend, wie viele von diesen Dingen auf einen selbst zutreffen. Dennoch ist es sehr amüsant zu lesen.

Bei Netways arbeiten wir sehr viel im Bereich Monitoring. So ist es kein Wunder, das ich bei den Dingen die jeder Sysadmin schon mal getan hat, sofort auch an dieses Thema denken musste. Lange muss man da auch nicht überlegen: Jeder Sysadmin hat mindestens schon ein mal in seiner Karriere ein monitoring Plugin geschrieben. Das gehört einfach dazu und selbst DevOps wird uns vermutlich nicht davor bewahren.

Das Schreiben von monitoring Plugins ist auf den ersten Blick ein ziemlich einfaches Thema. So ein Plugin muss einen Rückgabewert von 0, 1 oder 2 liefert und im besten Fall einen Text ausgeben, der den Zustand beschreibt. Damit wären schon mal alle Grundvoraussetzungen gegeben. Weil es eben so einfach ist, gibt es auch so viele von diesen Plugins. Sie werden in nahezu jeder Programmiersprache geschrieben. Manche Plugins sind umfangreich mit vielen Optionen und noch mehr Performance Daten in der Ausgabe. Andere wiederum bestehen nur aus wenigen Zeilen und erfüllen einen einzigen speziellen oder simplen Zweck.

Was mich bei monitoring Plugins schon immer gestört hat, ist das Deployment von jenen. Je nachdem in welcher Sprache das Plugin entwickelt ist, müssen mit cpan, gem, pip, npm, pear, composer oder andern Package Managern Abhängigkeiten nachinstalliert werden. So richtig lästig wird das bei ein paar Hundert Plugins für ein paar Tausend Server mit unterschiedlichen Distributionen. Sind Windows Systeme dabei, … ach davon fang ich garnicht erst an.

Welche Lösung gibt es also dafür? Noch keine fertige, zumindest meiner Meinung nach. Selbst Configuration Management löst das Problem nicht ganz. Um das vernünftig zu machen, müsste man ja seine 3-Zeiler Plugins packetieren und vernünftige Module oder Cookbooks schreiben, die das dann auf die Systeme ausrollen. Bestenfalls natürlich auf jedes System nur die Plugins die dort auch wirklich hin gehören. Seitdem ich mich bezüglich eines Projekts aber mit der Programmiersprache Go auseinander setze, beschäftigt mich ein anderer Ansatz um das Problem zu lösen: was wäre, wenn so ein Plugin gar keine Abhängigkeiten hat?

Go ist eine Programmiersprache, deren Wurzeln bei C liegen. Sie ist dementsprechend auch keine Scriptsprache wie Ruby oder Python, fühlt sich manchmal aber trotzdem so an. Das führt dazu das Leute wie ich, die aus der Scripting Welt kommen, sich sehr schnell wohl fühlen mit Go. Ob Go eine objektorientierte Sprache ist, da scheiden sich die Geister. Objekte im klassischen Sinne gibt es nicht, zumindest werden sie nicht so genannt. Betrachtet man es im Detail, kann man aber nachvollziehen warum es Stimmen gibt, die Go als objektorientiert bezeichnen.

Wie bei anderen Sprachen auch gibt es bei Go viele Libraries die verwendet werden können, sie werden aber Packages genannt. Der in Go geschriebene Code muss kompiliert werden. Ein großer Vorteil dabei ist, dass die entstandenen Binaries standardmäßig statisch gelinkt sind. Das heißt im Umkehrschluss es muss nichts nachinstalliert werden mit gem, pip, cpan usw. Alles steckt schon in dieser einen Binary. Sicherlich lässt sich dasselbe auch mit C, C++ oder anderen Sprachen erreichen. Keine ist aber so einfach und einsteigerfreundlich wie Go. Das zählt für mich als sehr großer Vorteil, schließlich werden diese Plugins oft von Sysadmins entwickelt, deren Hauptbeschäftigung nicht das Programmieren ist.

Statisch gelinkte Binaries könnten also das Problem der Abhängigkeiten lösen. Spinnt man die Idee weiter, könnte man mit einem “monitoring plugin” Package für Go ein Framework schaffen mit dem einheitliche Plugins entwickelt werden. Eine tolle Idee, wenn ihr mich fragt. Das Problem des packetierens lässt sich übrigens wunderbar mit fpm lösen, dazu aber vielleicht ein anderes Mal mehr.

Mein Aufruf an dieser Stelle also: Schreibt eure monitoring Plugins in Go, denn ich möchte mich nicht stundenlang damit Beschäftigen sie zum Laufen zu kriegen!

Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Get ready with NETWAYS

This entry is part 2 of 13 in the series Azubis erzählen

nerd_of_awesome_by_movillefacepalmplz-d5qvmzxGet ready with NETWAYS! Das trifft für mich auf die letzten 3 Jahre zu, in denen ich meine Ausbildung hier bei NETWAYS absolvieren durfte. An meinem ersten Tag, hatte ich keine Ahnung von Linux, Servern geschweige denn von OpenSource. Aber das hat hier niemanden abgeschreckt und mir wurde über die Zeit alles nötige beigebracht um selbstständig arbeiten und lernen zu können. Verschiedene Linux Distributionen, Hardware und Verkabelungen im Rechenzentrum, Pflege der HQ-Infrastruktur, Kundensupport und auch die Entwicklung einiger Automatisierungsskripte waren unter anderem Teil meiner Ausbildung hier. Ich empfand es als großen Vorteil, Teil einer verhältnismäßigen jungen und aufstrebenden Firma zu sein, allein schon deswegen, weil man jeden einzelnen Kollegen beim Namen kennt. Aber auch deswegen, weil eine Firma wie diese, viele neue Produkte testet und versucht sie in den produktiven Einsatz zu überführen. Manchmal erfolgreich, manchmal eher weniger. So bekommt man sehr viel von der “neuen Technik” mit und sieht in manchen Situationen auch wie es nicht geht.

Besonders überrascht war und bin ich teilweise immernoch, über den Umgang miteinander. Es herrscht ein eher freundschaftliches Verhältnis, sodass man auch in der Freizeit oder nach Feierabend mal zusammen einen trinkt, die ein oder andere Feier miterlebt oder eine LAN-Party veranstaltet. Auch Konferenzen und Schulungen in Nürnberg, Berlin, Köln, Düsseldorf, Barcelona oder den USA waren bisher immer ein sehr angenehmes Erlebnis. Soweit also eine Firma, in der man jeden Tag aufs neue gern arbeitet.

Zu jeder Ausbildung gehört am Ende auch eine Abschlussarbeit in Form eines Projektes und dessen Dokumentation. Mein Projekt befasst sich damit, eine Docker-Registry aufzusetzen. In diesem Projekt war sehr viel gefordert. Ich musste mich in kurzer Zeit in ein neues Thema einarbeiten, eine virtuelle Maschine mit entsprechenden Anforderungen aufsetzen, Fehler korrigieren, so viel automatisieren wie möglich und alles anschließend dokumentieren. Als letztes gilt es dieses Projekt im Sommer einem Prüfungsausschuss zu präsentieren und sich deren Fragen zu stellen.

Nach erfolgreichem Abschluss meiner Ausbildung werde ich im Support arbeiten und versuchen unseren Kunden bestmöglich zu helfen. Ich freue mich auf die Arbeit und auch darauf weiterhin zu lernen und Erfahrungen zu machen.

Trotz alledem lernt man nie aus und es ist auch unmöglich alles beigebracht zu bekommen. Aber bei NETWAYS bekommt man eine sehr gute Vorbereitung auf den Alltag in der IT Branche nach der Ausbildung. Für den Fall, dass jemand auf der Suche nach einer geeigneten Firma ist, dann ist er bei uns an der richtigen Stelle!

 

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz