Terminal-Multiplexer: wie ich diese Seite vom Smartphone aus baue

Den Großteil dieser Website habe ich auf einem iPhone und einem iPad gebaut: auf dem Sofa, im Zug, wo ich gerade war. Das MacBook kam nur für UI-Arbeit raus, wenn ich einen großen Bildschirm und einen echten Desktop-Browser brauchte, um Layouts und Details zu prüfen, und für größere Handarbeit im Code, bei der ein Touchscreen zu fummelig wird.

Das klappt nur, weil keins dieser Geräte die eigentliche Arbeit macht. Alles läuft auf einem kleinen Server, und jedes Gerät ist nur ein Fenster in dieselbe Terminal-Session. Das Stück, das das möglich macht, ist ein Terminal-Multiplexer.

1. Was ein Multiplexer macht

Ein Terminal-Multiplexer hält deine Terminals auf dem Server statt auf dem Gerät vor dir. In einer Session hast du Tabs und Panes nebeneinander: den Editor in einem, den Build im nächsten, die Tests im dritten, die Git-Historie im vierten.

Das Entscheidende: Die Session lebt, solange der Server läuft. Schließt du die App, reißt die Verbindung ab oder wechselst du das Gerät, hält nichts an. Du verbindest dich neu, und alles ist genau da, wo du aufgehört hast, auch Programme, die in der Zwischenzeit weitergelaufen sind, samt allem, was sie ausgegeben haben.

2. Warum das in meinem Setup zählt

Meine Entwicklungsumgebung ist ein Server, der nur über ein privates Netz erreichbar ist. Meine Geräte halten die Projekte nicht, sie zeigen sie nur an. Das bringt ganz praktische Vorteile:

Gerätewechsel mitten in der Arbeit. Ich starte einen Build auf dem iPad, schaue mir das Ergebnis auf dem iPhone an und mache auf dem MacBook weiter, wenn die UI-Details dran sind. Alle drei zeigen dieselbe Session, keine drei Kopien.
Verbindungen dürfen abreißen. Auf dem Smartphone ist die Verbindung ständig weg: ein Tunnel, ein Aufzug, der Wechsel von WLAN auf Mobilfunk, die Bildschirmsperre. Die Arbeit auf dem Server merkt davon nichts.
Lange Jobs laufen weiter. Builds, Tests und Installationen laufen auf dem Server, nicht auf einem Smartphone, das Akku sparen will.
Eine Umgebung statt drei. Werkzeuge, Versionen und Einstellungen gibt es einmal, auf dem Server. Zwischen den Geräten muss nichts synchron gehalten werden.
Auf dem Gerät gibt es nichts zu verlieren. Auf Smartphone und Tablet liegen weder Code noch Zugangstokens. Geht ein Gerät verloren, ist die Arbeit nicht weg.

Dieses Setup hat auch meinen Alltag geprägt. Lange war ich viel unterwegs, und das mit leichtem Gepäck. Weil die Arbeit auf dem Server liegt, haben iPhone und iPad gereicht, um von überall aus weiterzuarbeiten, ohne unterwegs etwas neu einrichten zu müssen. Das MacBook konnte zu Hause bleiben, und das hat viel Gewicht gespart: Ein normal großer Rucksack als Handgepäck war mehr als genug.

3. Vorher: herdr

Vor Rex habe ich mit herdr gearbeitet. Das war mein erster Multiplexer in diesem Setup, und dort hat sich meine heutige Arbeitsweise geformt: Panes nebeneinander, Sessions, die auf dem Server weiterlaufen, und von überall aus wieder dorthin zurückkommen.

4. Heute: Rex

Heute arbeite ich mit Rex. Rex bringt eigene Apps für den Mac und für iPhone und iPad mit, und die verbinden sich direkt über das private Netz mit dem Server, ohne eine extra SSH-App dazwischen. Für ein Setup, das vor allem auf Smartphone und Tablet stattfindet, macht das einen Unterschied:

Für Touch gebaut. Eine Tastenleiste über der Tastatur hat die Tasten, die einer Smartphone-Tastatur fehlen, etwa die Pfeile, Escape und Tab, und ein gehaltener Pfeil wiederholt sich.
Neu verbinden gehört zum Konzept. Komme ich zu einem Tab zurück, zeigt er seinen letzten Bildschirm, während er sich neu verbindet, statt einer leeren Seite.
Überall dieselben Sessions. Die Mac-App und die Apps für iPhone und iPad zeigen dieselben Sessions, Tabs und Panes auf demselben Server.
Wer ich bin, sagt das Netz. Auf dem Server läuft Rex als Login-Server: Das private Netz sagt ihm, wer sich verbindet, und er öffnet die Session unter meinem eigenen Linux-Konto. Es müssen keine SSH-Schlüssel aufs Smartphone kopiert werden.
Nichts offen zum Internet. Rex ist nur über das private Netz erreichbar, wie alles andere auf dem Server.

5. Wann das MacBook rauskommt

Smartphone und Tablet decken Code schreiben, Builds starten, Logs lesen und Committen ab. Aufs MacBook wechsle ich in zwei Fällen:

UI-Arbeit. Layouts, Abstände, Animationen und die Details der Pixel-Cover brauchen einen großen Bildschirm und einen Desktop-Browser.
Größere Handarbeit im Code. Eine lange Datei von Hand umbauen, Blöcke verschieben oder viele Zeilen auf einmal feinjustieren wird auf einem Touchscreen zu fummelig. Mit echter Tastatur, Trackpad und genauer Textauswahl geht das schneller und präziser.

Der Wechsel selbst ist kein Bruch. Die Mac-App öffnet dieselbe Session, in der ich eben noch auf dem iPad gearbeitet habe, mit denselben Tabs, demselben Verlauf und dem Build, der noch läuft. Das Gerät wechselt, die Arbeit nicht.

Kurz gesagt

Ein Terminal-Multiplexer hält Terminals, Tabs und Panes auf dem Server, damit sie geschlossene Apps, abgerissene Verbindungen und Gerätewechsel überstehen.
Mit einem Setup auf dem Server wird jedes Gerät zum Fenster in eine Umgebung: Smartphone, Tablet oder Laptop.
Auf Smartphone und Tablet zählt, wie der Multiplexer sich verbindet, genauso wie das, was er kann. Deshalb arbeite ich mit Rex und seinen eigenen Apps.

Wenn du so eine Entwicklungsumgebung für dich oder dein Team möchtest, melde dich.