Meine überarbeitete Website habe ich zu großen Teilen in freier Natur mit vim geschrieben. Nicht immer habe ich dafür einen Laptop benutzt. Auch das Smartphone, ein iPad oder Zuhause der stationäre Rechner, kamen zum Einsatz.

Damit ich unabhängig vom Gerät die gleiche Entwicklungsumgebung habe, musste ich mich erst mal mit dem Gedanken anfreunden, dass ich mich von der grafischen Oberfläche meines hoch geschätzten Atom-Editors verabschieden muss und die Grundlagen von vim, als Texteditor, und tmux, als Terminal Multiplexer, zu lernen habe. Beides Programme die auf der Kommandozeile laufen. Denn nur die Kommandozeile ist auf jedem Gerät und jedem OS installierbar und somit der kleinste gemeinsame Nenner aller Geräte, sei es Smartphone, Tablet oder Computer. Diese beiden Programme sind der Schlüssel zum Cloud Computing. Die wichtigste Rolle spielt dabei tmux.

Was ist tmux?

Tmux sorgt dafür, dass auch nach dem Ausloggen aus der Shell die Session auf der Maschine weiter ausgeführt wird. Normalerweise werden alle Prozesse die während einer SSH Verbindung ausgeführt werden, nach dem Beenden der Remote Session beendet. Ein laufender Download bspw. wird nur so lange ausgeführt, wie man sich in der Session befindet. Tmux sorgt dafür, dass der Prozess auch dann auf der Maschine weiterläuft, nach dem man die Session beendet hat. Solange der Server nicht herunterfährt, laufen alle Prozesse auch nach dem Ausloggen noch. Ich kann also zu jedem späteren Zeitpunkt die Arbeit an genau der Stelle wieder aufnehmen, an der ich sie beendet habe, ganz egal mit welchem Gerät ich mich auf den Server verbinde.

Tmux ist ebenfalls eine Art Windowmanager. Innerhalb einer tmux Session kann ich parallel unabhängig von einander laufende Sessions betreiben, also mehrere Fenster erstellen. Ich habe bspw. für jede Aufgabe ein Fenster, in der tmux Session. Zum Beispiel verwende ich eine ähnliche Konfiguration wie die folgende: Auf Fenster 0 ist vim im Verzeichnis der Templatedateien geöffnet. Im Fenster 1 ist vim im Javascript Verzeichnis geöffnet. Im Fenster 2 ist vim im SASS Verzeichnis geöffnet. Auf der 3 mache ich git. Auf der 4 ist das Root Verzeichnis des Projekts. Auf der 5 der Lynx Browser. Auf der 6 mein Home Ordner …. usw. So kann ich sehr schnell zwischen den zu bearbeitenden Datien wechseln. Tmux kann jedes einzelne Fenster auch horizontal und vertikal teilen, wenn man zwei Dokumente parallel nebeneinander geöffnet sehen will.

Sogar das parallele Arbeiten mit mehreren Rechnern in der selben tmux Session ist möglich. So kann ich mitverfolgen, was über die zweite Verbindung gerade auf der SSH Session gemacht wird. Absolute Synchronizität ist damit gesichert. Voraussetzung ist, dass der Server dauerhaft an ist. Ansonsten kann man sich auch Startscripte für rmux schreiben, die eine Session mit allen Fenstern, Programmen und Dateien erzeugt, die man benötigt. So ein Script sollte pro forma angelegt werden. Fährt der Server doch mal runter, ist die mühsam eingerichtete tmux-Umgebung nämlich futsch. Man fängt von vorne an seine Fenster, Programme und Dateien neu aufzurufen und einzurichten. Ein Startscript automatisiert diesen Prozess.

Zentrale Lösung: NAS

Nun kann ich nicht anfangen tmux und vim auf Smartphone, Tablet und verschiedenen Rechnern zu installieren und die Konfigurationen synchron halten. Das ist technisch nicht möglich und wenn doch, viel zu umständlich. Zum Glück habe ich eine Synology Diskstation, ein NAS. Auf den Server kann ich mit SSH von jedem Gerät aus zugreifen, egal ob ich Zuhause im eigenen Netzwerk bin oder unterwegs im Handynetz, egal ob ich vor einem Smartphone, Tablet oder Computer sitze. Auf meinem Server habe ich mir nun peu à peu meine Entwicklungsugebung aus Plugins, Syntaxhighlightern, Snippets, Tastenkürzeln usw., aufgebaut.

SSH Verbindung herstellen

Um eine SSH Verbindung auf den Server aufzubauen, kann man entweder per VPN Verbindung ins Heimnetz gehen und dann die lokale IP des Servers anrufen oder gleich den SSH Port am Router öffnen und ohne Umweg auf die Shell zugreifen. Wer seinen SSH Port nicht öffnen möchte, greift zu Lösung 1 oder überlegt, ob er nicht einfach den Standardport von SSH ändern möchte.
Auf Android kann ich als SSH Client JuiceSSH empfehlen, mit dem ich gerade diese Zeilen schreibe, oder auf iOS: Serverauditor. JucieSSH ist meiner Meinung nach ein hervorragender SSH Client, der sogar Swipe Gesten in Fensterwechsel unter tmux umwandelt.
Wer vom Rechner eine SSH Verbindung aufbauen will, gibt normalerweise ssh NUTZERNAME@DOMAIN_ODER_IP.DE:PORT ein. Wenn man mehrere SSH Verbindungen managt, kann die Schreiberei und das Merken nerven. Es lohnt sich im Verzeichnis ~/.ssh eine Datei mit Namen config anzulegen. Dort kann man seine Verbindungen mit Aliasen versehen. Ein Eintrag sieht bspw. so aus:
Host ALIAS_EINTRAGEN
HostName IP_ODER_DNS
User NUTZERNAME
Für mehr Informationen einfach mal nach ssh config im Internet suchen

Weitere Argumente für einen Heimserver

Ein weiterer Punkt der für die Lösung mit dem Heimserver spricht, ist der Fakt, dass ich nicht nur vim auf allen Geräten hätte installieren müssen, sondern auch alle Prozessoren, die für die Entwicklung unabdingbar sind. Das sei zum Beispiel der Static Site Generator jekyll, den ich für meine statische Seite als Grundlage ausgewählt habe. Er benötigt zum generieren der HTML Dateien aus meinen Templates Ruby. Man kann doch nicht Ruby auf jedem Rechner installieren, von dem aus an der Website gearbeitet werden soll… Hinzu kommen noch git und in der weiteren Entwicklung Grunt, imagemagick und mehr.
Um eine Pflege über mehrere Rechner zu ermöglichen, hätte man als erste Idee auch git als zentrale Lösung verwenden können, um so alle Projektdaten zwischen den Geräten mit viel Handarbeit synchron zu halten. Git verwende ich zur Dokumentation und Versionierung zwar sowieso, wäre aber wieder nur schwer auf Smartphone und Tablet zu implementieren gewesen. Ein ständiger Push und Pull Workflow ist zudem noch sehr fehleranfällig, wenn man nicht gewissenhaft arbeitet. Mit der zentralen Lösung eines Entwicklerservers, der per SSH angesprochen wird, installiere ich alle Softwarebausteine ein einziges Mal auf einem Gerät und habe unabhängig von der technischen Spezifikationen des Client immer die exakte selbe Rechenleistung, Speicherstände und Arbeitsumgebung zur Hand.

Entweder, oder. Doch allein schon mit Smartphone und Tastatur kann man produktiv werden.

Außer Haus arbeiten

Damit ich von unterwegs mit dem Tablet, Laptop oder Smartphone auch auf den Heimserver komme, brauchte ich einen mobilen Accesspoint. Dazu habe ich mir günstig auf eBay einen Huawei E5331s gekauft. Man kann natürlich auch einfach mit seinem Handy einen Hotspot errichten oder bspw. aus einem RaspberryPi einen mobilen Accesspoint basteln. Da sich die Übertragungsrate bei SSH Verbindungen im untersten Kilobytebereich bewegt, kann auch mit überzogenem Datenvolumen problemlos weitergearbeitet werden.
Für den Anfang reicht auch eine Karte von netzclub, kostenlos 100 MB jeden Monat. Man bekommt Werbung im Gegenzug.
Für die Arbeit am Smartphone ist es ratsam Displaygrößen von ca. 5.5 Zoll zu haben. Auch ein faltbarer Ständer und eine Bluetooth Tastatur erleichtern das Arbeiten. So hat man mit wenig Gepäck und wenig Stromaufgebot eine portable Entwicklungsumgebung.

Browsertests

Zur Kontrolle der Entwicklung gibt es je nach Arbeitsschritt verschiedene Möglichkeiten. Will man wissen, ob die Textstelle eingepflegt wurde, kann man den terminalbasierten Lynx Browser verwenden, um Datenvolumen zu sparen. Wenn man seinen CSS Code im Browser kontrollieren will, helfen Browser Plugins, die nur die CSS Datei neu laden (CSS Reloader – FireFox). Auch hilfreich sind Plugins, die einzeln das Laden von JS, CSS, Bildern, Cookies, Flash usw. verhindern können. Sehr gut gefällt mir das QuickJava Addon für Firefox, das allgemein gut ist, wenn man unnötige Datenmengen im Handynetz sparen möchte. Auch das automatische Nachladen der CSS-Datei bei erkannten Änderungen an selbiger ist ja bekanntlich mit Addons möglich. Der Opera Browser ist darüber hinaus in der Lage Traffic zu sparen, in dem er die angeforderte Seite zu erst auf den operaeigenen Servern komprimiert und die komprimierte Version in den Browser zurückschickt.

ca. 800g schwer, sorgt aber für deutlich höhere Reichweite

Stromversorgung

Ein weiteres Hindernis ist der Strom unterwegs. Will man im Park über längere Zeiträume verweilen und hat am Laptop nur Akkulaufzeiten von ca. 3 Stunden, der sollte sich überlegen eine Powerbank der größeren Sorte zu bestellen. Ich habe mir von revolt eine 45 Ah (45.000 mAh) Powerbank besorgt, die meinen MacBook Air (von 2009) über 8 Stunden (!) mit Strom versorgen kann. Hinzu kämen die 3 Stunden aus dem eingebauten Akku. Völlig unabhängig von kurzen Akkulaufzeiten zu sein macht sich auch dann bezahlt, wenn man auf einem Fototermin im Freien ist, und man seine Fotos vor Ort sichten und bearbeiten muss. Gerade wenn die Prozessorlast hoch ist, kommt man nicht sehr weit. Die besagt Powerbank hat auch USB Anschlüsse, falls der Accesspoint nachgeladen werden muss.

Optimierung der SSH Verbindung

Im laufenden Betrieb einer SSH Verbindung über das Handynetz stellt man fest, dass bei Denkpausen ab 5 Sekunden die Verbindung unterbrochen wird. Um dem Abhilfe zu schaffen, läuft neben der SSH Session auch noch ein Ping, der alle 1–2 Sekunden 2 Bytes zu Google.de schickt. So bleibt die Verbindung immer gut ansprechbar. ping -i 2 -s 2 google.de

Jekyll Websites mit Synology Diskstation rendern

Da man nicht ohne weiteres auf einer Diskstation jekyll installieren kann, habe ich mir einen jekyll Dockercontainer heruntergeladen. Als Volume gibt man den Root-Pfad vom Projekt an und als Mount-Pfad /srv/jekyll. Sobald der Container läuft versucht er aus den Template Dateien eine fertige Seite nach _site/ zu schreiben. Weil man während der Entwicklung nicht immer über das Webinterface der Diskstation gehen will, um das Protokoll von jekyll zur Fehleranalyse auszuwerten, kann man den Container über das Terminal steuern. docker logs --since 10m NAME_DES_CONTAINERS zeigt stdout der letzten 10 Minuten von dem Container an. Wenn man was an der _config.yml ändert, muss der Container neu gestartet werden. Das passiert mit docker restart NAME_DES_CONTAINERS. Die Seite wird mit http://SERVERADRESSE:4000 im Browser aufgerufen.

Zusammenfassung

Ich habe hier nur grob angerissen, was ich auf meinem Weg bisher gelernt habe. Im Großen und Ganzen ist es eine lohnenswerte Investition (zeitlich vor allem) gewesen, das System wie beschrieben einzurichten. Mit vim umgehen lernen macht viel Freude und macht einen frei von grafischen IDEs. Wenn vim auf nur einer Maschine eingerichtet werden muss, die per SSH erreichbar ist, erspart man sich das x-malige Einrichten seiner IDE auf den verschiedenen Geräten, was technisch manchmal sogar unmöglich wäre.
Geräteunabhängig, stromsparend, zeitsparend: ich glaube das macht die Lösung mit dem NAS so interessant und flexibel einsetzbar. Auch weil dort noch Dienste wie der eigene Git Server, Docker, node.js und weitere Pakete per ipkg zum Laufen gebracht werden können, hat man alles unter einem Hut. Es entsteht eine schlanke textbasierte Cloud im Terminal, die man in vielerlei Hinsicht produktiv verwenden kann. Mit dieser Geräteunabhängigkeit kann ich viele Aufgaben stromsparender und ortsunabhängiger und damit effizienter erledigen. Auf in eine Zukunft mit einem schlanken tragbarem Büro…