Internet Relay Chat (IRC) und E-Mail

Nach wie vor sind IRC und E-Mail unsere beliebtesten und wichtigsten asynchronen Kommunikationswerkszeuge.

In Zeiten, in denen (gefühlt) jede Woche eine neue Messaging-App erscheint, die noch bessere Kommunikationsmöglichkeiten verspricht, mag IRC ein wenig angestaubt erscheinen. Für unsere Entwickler gehört der IRC aber allein deswegen schon zum Tagesgeschäft, weil er in vielen Open-Source-Projekten oft die bevorzugte Variante ist, um miteinander im Chat zu diskutieren.

Außerdem lässt sich der Dienst einfach auf eigener Infrastruktur betreiben und mit diversen simplen Clients nutzen, sodass unsere Mitarbeiter nicht gezwungen sind, (private) Smartphones für wichtige Kommunikation zu nutzen. Außerdem hat IRC den großen Vorteil, dass man nicht durch eine Flut von Bildern und Videos, die einen nicht wirklich interessieren, aus der Arbeit gerissen wird. ;-)

Unsere übliche projektbezogene Kommunikation läuft nach wie vor über Mailinglisten.

Voice-Chat dank Mumble

Wir nutzen bereits seit längerem Mumble, einen Open-Source VoIP-Chat-Server, um uns mit unseren remote arbeitenden Kollegen zu unterhalten. Diese bei gemeinsamen Onlinespielen gebräuchliche Konferenzsoftware ist nun unsere virtuelle Kaffeetheke geworden. Über Mumble können wir sowohl unsere regelmäßigen Stand-Up-Meetings in großer Runde fortsetzen als auch in kleineren Gruppen themenbezogene Diskussionen starten.

Empfehlung: bei einer dauerhaften Konferenzschaltung – unabhängig von der Softwarelösung – die persönlichen Einstellungen auf Push To Talk setzen. Eure Gesprächspartner werden es Euch danken.

Zeigen und Erklären – Jitsi

Trotz aller bisher gut funktionierender Kommunikation reicht es manchmal nicht aus, nur miteinander zu reden. Bei der gemeinsamen Arbeit ist es zwischendurch hilfreich und wichtig, gemeinsam auf einen Bildschirm oder ein Stück Hardware zu schauen – oder doch in das Gesicht, um die Person gegenüber besser zu verstehen.

Für diese Fälle haben unsere Admins einen Jitsi-Server aufgesetzt. Die ersten vorsichtigen Erfahrungen mit der im Browser laufenden Videokonferenz sind selbst bei längeren Konferenzschaltungen mit einigen wenigen Teilnehmern auch bei geringer Bandbreite recht vielversprechend. Wir planen, in den nächsten Tagen noch einige Performance-Tests durchzuführen.

Unser Remote-Setup

Wir haben in den letzten Jahren sowohl softwareseitig als auch mit spezialisierter Hardware viel Aufwand in Technik investiert, die das Remote-Arbeiten an unseren Kunden-Boards ermöglicht. Mit dem nun folgenden Einblick in unsere Arbeitsumgebung hoffen wir, auch andere zu inspirieren:

Jedes Remote-Lab besteht aus den folgenden Komponenten:

• einem über das Netzwerk kontrollierbaren Power Switch (Gude oder netio),
• einem über Ethernet kontrollierbaren Seriellen Server (siehe RFC 2217),
• einem Netzwerkswitch und
• einem kleinen Server.

Einige Remote-Labs haben außerdem

• eine CAN-Infrastruktur, für erweriterte Schaltaufgaben (IO)
• USB-Hubs, um USB-Geräte zu kontrollieren.

Unser Open-Source-Hardware-Automatisierungstool labgrid ist dann die Komponente, die Hard- und Software verbindet, indem sie die physikalischen Ressourcen abstrahiert und auf den Monitor der Entwickler bringt.

Dafür läuft auf dem kleinen Server in jedem Remote-Lab ein 'labgrid exporter', der automatisch eine virtuelle "Ressource" für jede verfügbare Fernsteuer-Hardware im Lab anlegt. Das kann dann zum Beispiel ein Powerswitch, eine serielle Konsole, ein USB-Gerät, oder ein CAN-IO sein.

Diese Ressourcen lassen sich zu sog. Plätzen gruppieren, wodurch sich Ressourcen unter einem einfachen, abstrakten Namen, wie bspw. "mein_entwicklungsboard", zusammenfassen lassen.

Jeder Entwickler kann nun eine lokale Instanz des labgrid-Clients benutzen, um zum Beispiel Plätze zu sperren, ein Board neu zu starten oder per serieller Konsole auf dieses zuzugreifen.

Auf einer zentralen VM läuft ein 'labgrid coordinator'. Dieser koordiniert die Zugriffe von den labgrid-Clients auf die Ressourcen der 'labgrid exporter'.

Der Unterschied, ob die Hardware nun von den Schreibtischen im Büro oder per SSH aus dem Homeoffice gesteuert wird, ist dabei so minimal, dass sich nun der Aufwand, den wir in den Aufbau dieser Infrastruktur gesteckt haben, bezahlt macht.

Hilfreiche Tools

Trotzdem gibt es immer noch Tätigkeiten, die sich in der Embedded-Entwicklung nicht so einfach automatisieren lassen. Ein Beispiel wäre, eine SD-Karte mit einem neuen Softwarestand zu bespielen und diese wieder in das Board zu stecken. Zumindest für diesen Fall hat unser Partner Linux Automation GmbH den USB-SD-Mux entwickelt.

Der USB-SD-Mux ist eine kleine Platine, die an einem Ende wie eine µSD-Karte geformt ist und am anderen Ende einen µSD-Karten-Slot enthält. Der USB-SD-Mux wird nun anstelle einer µSD-Karte in das Board geschoben, und die eigentliche µSD-Karte wird in den USB-SD-Mux gesteckt. Der USB-SD-Mux wird mittels USB-Kabel mit einem Host-PC verbunden und kann so die Karte zwischen dem Host-PC und unserem Board („Device under Test“) umschalten. Im Host-PC erscheint die SD-Karte als ein ganz normaler USB-Massenspeicher und kann dort einfach neu beschrieben werden.

Da uns selbst noch zahlreiche weitere Automatisierungen fehlen, sind bereits die nächsten Werkzeuge in der Entwicklungs- und Testphase. Darunter sind der ETH-Mux, der Ethernet schalten wird (um die Kabel nicht mehr abziehen und neu stecken zu müssen), und ein USB-OTG-Mux, der das Stecken eines USB-Sticks simuliert. Dazu bald mehr… :-)

Obwohl wir das Gefühl haben, dass unsere Remote-Infrastruktur gut aufgestellt ist und wir keine Probleme haben, weiter zu arbeiten, hoffen wir doch darauf, dass wir uns bald wieder an der Kaffeetheke treffen können und wir die Krise gut überstehen.

Bleibt gesund!