Sie können von Ihrem Telefon aus zu GitHub pushen, aus dem Bett, und es ist in iOS eingebaut

Was Ihr Telefon bereits kann

Die Kurzbefehle-App auf einem iPhone hat eine Aktion namens Skript über SSH ausführen.

Das ist alles. Das ist die ganze Überraschung. In der App, die Apple Ihnen zum Stellen von Weckern und Abspielen von Musik verkauft, steckt ein funktionierender SSH-Client, er behandelt Schlüssel korrekt, und Sie können ihn auf Ihren eigenen Computer richten und dort alles ausführen.

Ich bin seit dreißig Jahren Ingenieurin und wusste es nicht. Niemand erwähnt es, weil Kurzbefehle an Menschen vermarktet wird, die ihre Morgenroutine automatisieren, und die Leute, die das hier wollen würden, lesen dieses Marketing nicht.

Also: Sie können von Ihrem Telefon aus zu GitHub pushen, und Sie müssen nichts installieren.

Warum ich es brauchte, und es ist keine Bequemlichkeit

Ich sollte offen sagen, woher das kommt, denn es ist kein Produktivitätstrick.

Meine dominante Hand funktioniert nicht. Sie ist seit fast zwei Jahren verletzt und war eines davon vollständig gelähmt. Auf einem Telefon zu tippen ist für mich nicht leicht lästig. Es tut weh, und es ist der Grund, warum Dinge nicht erledigt werden.

Das heißt, die eigentlichen Kosten des Veröffentlichens waren nie das Schreiben. Es war, dass Veröffentlichen verlangte, dass ich aufrecht an einem Schreibtisch sitze, mit beiden Händen, und drei Git-Befehle fehlerfrei tippe. An einem Tag, an dem mein Rücken schmerzt oder meine Hand schlecht ist, ist das der Unterschied zwischen einem Beitrag, der erscheint, und einem, der nicht erscheint.

Die Aufgabe war also eng gefasst, und es ging nicht um Zeitersparnis. Vom Liegen bis zum Veröffentlichen kommen, ohne eine Tastatur zu berühren.

Ein Telefon ist kein Terminal

Das ist der Satz, um den sich der ganze Bau drehte, und am Anfang hatte ich ihn nicht. Ich bin darauf gekommen, indem ich Dinge falsch gemacht habe.

Ein Telefon ist kein kleiner Computer, an dem man arbeitet. Es ist ein Auslöser. Sie werden darauf keinen Befehl tippen, Sie werden darauf keinen Stacktrace lesen, und Sie werden darauf ganz sicher keinen Befehl bearbeiten und es noch einmal versuchen. Es gibt kein zweites Fenster. Es gibt keinen Scrollback.

Sobald man das akzeptiert, treffen sich drei Entwurfsentscheidungen von selbst.

Die Intelligenz gehört auf die Maschine mit der Tastatur. Meine erste Fassung steckte den ganzen Befehl in den Kurzbefehl. Das ist falsch, und ich komme darauf zurück.

Die Ausgabe zählt mehr als sonst, denn sie ist das Einzige, was Sie bekommen. Sie können nichts nachsehen. Was das Werkzeug sagt, ist die gesamte verfügbare Wahrheit.

Und es darf Sie nie um eine Entscheidung bitten. Ein Tippen, ein Satz, fertig, sonst hat es die einzige Aufgabe verfehlt, die es hatte.

Ein Telefon ist kein Terminal. Es ist ein Auslöser. Jede Entscheidung danach folgte aus diesem einen Satz.

Im eigenen Netzwerk, und dort würde ich anfangen

Ich habe bewusst zuerst die Fassung gebaut, die zu Hause funktioniert, weil sie einfach ist und weil nichts dem Internet ausgesetzt wird. Mein Mac hat eine 192.168-Adresse, die von außen nicht erreichbar ist. Ein Angreifer müsste in meiner Wohnung sein und mein entsperrtes Telefon halten, und dann ist meine Shell nicht seine interessanteste Option.

Auf dem Mac ein einziger Schalter. Systemeinstellungen, Allgemein, Freigaben, Entfernte Anmeldung. Stellen Sie sie so ein, dass nur Ihr eigenes Konto erlaubt ist.

Und eine Sache, die niemand erwähnt und die Sie eine Stunde kostet. In derselben Ansicht steht Vollzugriff auf das Volume für entfernte Benutzer erlauben. Aktuelle macOS-Versionen hindern eine SSH-Sitzung daran, Ihren Dokumente-Ordner zu lesen, solange das aus ist. Meine Projekte liegen in Dokumente. Ohne das verbindet sich der Kurzbefehl einwandfrei und findet dann nichts, und der Fehler sagt Ihnen nicht, warum.

Dann der Schlüssel. Die Kurzbefehle-Aktion erzeugt ihn für Sie, ein ed25519-Paar. Die private Hälfte bleibt auf dem Telefon und bewegt sich nie. Die öffentliche Hälfte installieren Sie auf dem Mac, indem Sie eine Zeile in ~/.ssh/authorized_keys ergänzen, und die Rechte sind keine Dekoration: Der SSH-Server weigert sich stillschweigend, diese Datei zu benutzen, wenn der Ordner oder die Datei für andere beschreibbar ist. Das ist der zweithäufigste Grund, warum es scheinbar nicht geht.

mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys        # den öffentlichen Schlüssel einfügen, eine Zeile
chmod 600 ~/.ssh/authorized_keys

Beim ersten Verbinden erscheint ein Hinweis, dass der Host noch nie gesehen wurde, mit einem Fingerabdruck. Das ist richtiges Verhalten und Sie bestätigen es einmal. Wenn Sie es bei derselben Maschine je wieder sehen, halten Sie an, denn dann hat sich der Host-Schlüssel geändert.

Halten Sie das Telefon dumm

Meine erste Fassung hatte alles im Kurzbefehl. Verzeichnis wechseln, hinzufügen, committen, pushen, aneinandergehängt in einer langen Zeile in einem Textfeld auf einem Telefon.

Es funktionierte etwa einen Tag. Dann nicht mehr, und ich sah auf einen langen Befehl in einem winzigen Feld, ohne erkennen zu können, was er tatsächlich getan hatte.

Also wanderte alles in eine Datei im Repository, deploy/publish.sh, und der Kurzbefehl führt jetzt eine kurze Zeile aus. Der Unterschied ist nicht Eleganz. Er ist, dass das Skript dort liegt, wo ich es an einer echten Tastatur bearbeiten kann, dass es mit dem Rest der Seite in Git liegt, und dass seine Kommentare sich dem erklären, der sie als Nächstes liest, mich in sechs Monaten eingeschlossen.

bash ~/Projects/ihre-seite/deploy/publish.sh [Bei jeder Ausführung fragen]

Der Kurzbefehl wurde zu vier Feldern und einem Satz. Alles Schwierige liegt auf dem Mac.

Das Erste, was kaputtging, war ein Anführungszeichen

Ich habe die Commit-Nachricht in Anführungszeichen übergeben, so wie man es in jedem Terminal tun würde.

iOS ersetzt gerade Anführungszeichen beim Tippen durch typografische. Bash behandelt ein typografisches Anführungszeichen nicht als Anführungszeichen. Eine ganz gewöhnliche Nachricht kam also beim Skript als drei einzelne Wörter mit zwei seltsamen Zeichen daran an, und das Skript nahm das erste Wort und ignorierte den Rest.

Die Korrektur sind drei Zeilen: alles nehmen, was übergeben wurde, statt nur das erste Argument, und die typografischen Zeichen entfernen. Aber die Lehre ist die, die sich verallgemeinern lässt. Das Textfeld ist nicht neutral. Irgendetwas zwischen Ihrem Daumen und Ihrem Programm bearbeitet hilfsbereit, was Sie getippt haben, und sagt es Ihnen nicht.

Das Zweite war ein PATH mit vier Verzeichnissen

Das Skript baut die Seite, bevor es committet. Es scheiterte sofort mit der Meldung, npm sei nicht installiert.

npm ist installiert. Es funktioniert in meinem Terminal einwandfrei.

Ein über SSH ausgeführter Befehl ist weder eine Login-Shell noch eine interaktive, also läuft nichts von Ihrer Shell-Konfiguration. Weder .zshrc noch .zprofile. Nichts, was Homebrew in Ihren PATH setzt, geschieht jemals.

Hier ist der tatsächliche PATH, den mein Skript bekam, aus dem Protokoll:

PATH=/usr/bin:/bin:/usr/sbin:/sbin

Vier Verzeichnisse. npm liegt in /opt/homebrew/bin, und das ist keines davon. Das Skript sieht jetzt an den üblichen Stellen nach, bevor es entscheidet, dass ein Werkzeug fehlt, und wenn es es dann immer noch nicht findet, sagt es das und macht ohne den lokalen Build weiter, statt die Arbeit zu verweigern.

Das erwischt jeden einmal, und so verwirrend ist es, weil die Sache nachweislich funktioniert, wenn man sie von Hand testet. Sie testen sie in einer anderen Welt.

Das Dritte war meines, und es war das schlimmste

Ich führte den Kurzbefehl aus. Er zeigte mir ein Feld mit einem einzigen Zeichen.

0

Mehr nicht. Zwei von uns sahen darauf, und keiner konnte etwas daraus lernen. Wir hatten keine Ahnung, ob er verbunden hatte, den Ordner gefunden, gebaut, committet, verweigert oder sich zerlegt hatte.

Ich kam schließlich darauf, indem ich zwei Läufe im Protokoll verglich. Wenn das Skript erfolgreich endet, zeigt das Telefon alles, was es ausgegeben hat. Wenn das Skript mit einem Fehlercode endet, wird die Ausgabe verworfen und Sie bekommen 0.

Lesen Sie das noch einmal, denn das ist die ganze Lehre. Der Moment, in dem das Werkzeug mir etwas Wichtiges zu sagen hatte, war genau der Moment, in dem es garantiert nichts sagen würde.

Die Korrektur klingt falsch und ist richtig. Jeder Weg durch dieses Skript endet jetzt erfolgreich und trägt die schlechte Nachricht stattdessen in Worten. Nichts Automatisches liest diesen Exit-Code. Ein Mensch tut es, und der Mensch liegt im Bett. Statt 0 bekommen Sie also einen Satz, der mit NOTHING DONE beginnt, und dann den Grund.

Und das, was ich von der ersten Minute an hätte tun sollen: Jeder Lauf schreibt eine vollständige Spur in eine Protokolldatei, und jede Meldung des Skripts endet damit, wo dieses Protokoll liegt. Die beiden echten Fehler oben waren in Minuten gefunden, sobald es das gab. Sie waren unsichtbar gewesen, nicht schwierig.

Die Regel, die ich daraus mitnehme

Ein Werkzeug, das sein eigenes Scheitern nicht erklären kann, ist nicht fertig, so gut es auch funktioniert, wenn es funktioniert.

Ich wusste das. Ich habe es anderen gesagt. Und trotzdem habe ich ein Skript ausgeliefert, dessen gesamtes Fehlervokabular aus einem Zeichen bestand, und ich habe es nur bemerkt, weil das Erste, was ich damit tun wollte, schiefging.

Es lohnt sich, das bei allem zu fragen, was Sie gebaut haben und das jemand benutzt, wenn Sie nicht danebenstehen. Nicht, ob es funktioniert. Ob es ihm sagen kann, was es getan hat.

Wann es baut, und die Frage, die es besser gemacht hat

Ursprünglich baute das Skript vor jedem Push die ganze Seite, was etwa fünfundzwanzig Sekunden dauerte. Dann habe ich mich laut gefragt, warum, und diese Frage lohnt sich öfter.

Die ehrliche Antwort ist, dass es nicht nötig war. Die Deployment-Pipeline baut sie ohnehin erneut, prüft das Ergebnis und veröffentlicht nichts, wenn eine der Prüfungen fehlschlägt. Die Live-Seite kann so oder so nicht kaputtgehen.

Der lokale Build bringt also zwei kleine Dinge: Man erfährt es in zwanzig Sekunden statt in drei Minuten, und ein Commit, der nicht baut, landet nicht in der Historie. Und er kostet fünfundzwanzig Sekunden bei jedem Push, was, wenn der Push ein Tippen aus dem Bett ist, fast das ganze Erlebnis ausmacht.

Jetzt baut es nur, wenn sich etwas geändert hat, das einen Build tatsächlich kaputt machen kann. Ein Beitrag baut. Ein Bild, eine Karte, ein Shell-Skript oder ein Dokument geht in etwa zwei Sekunden durch. Eine Regel statt einer Gewohnheit, und das Protokoll sagt, welche angewendet wurde, damit es nie rätselhaft sein kann.

Wie es sich jetzt anfühlt

Ich tippe auf ein Symbol. Ein Feld fragt, was sich geändert hat. Ich sage ein paar Worte. Wenige Sekunden später sagt es mir, was es getan hat.

Nichts hiervon speist den Build, also direkt durch. Gepusht, eine Datei. In wenigen Minuten live.

Das ist aus der Küche oder aus dem Bett, mit einem schlafenden Laptop in einem anderen Zimmer. Und an einem Tag, an dem meine Hand oder mein Rücken schlecht ist, ist das der Unterschied zwischen dem Beitrag der Woche, der erscheint, und dem, der nicht erscheint.

Es ist ein kleines Stück Technik. Es ist keine kleine Veränderung.

Was noch nicht fertig ist

Das funktioniert in meinem eigenen Netzwerk. Gehen Sie zur Haustür hinaus, und es hört auf.

Das nächste Stück ist eine private Verbindung zwischen Telefon und Mac, die über Mobilfunk funktioniert, ohne irgendetwas dem Internet auszusetzen, damit ich morgens mit meinem Hund rausgehen, die Maschine zu Hause laufen lassen und trotzdem veröffentlichen kann. Was ich nicht tun werde, und was Sie auch nicht tun sollten, ist einen Port in Ihrem Router weiterzuleiten. Das stellt Ihren Mac ins offene Internet, um zwanzig Minuten zu sparen.

Wenn diese Hälfte gebaut ist, ergänze ich sie hier, statt einen zweiten Beitrag zu schreiben, und Sie können beide Hälften sehen und die erste danach beurteilen, wie ehrlich ich die zweite beschrieben habe.

Wenn Sie es ausprobieren wollen

Alles, was Sie brauchen, ist bereits auf Ihren beiden Geräten. Entfernte Anmeldung auf dem Mac, die Aktion Skript über SSH ausführen auf dem Telefon, ein Schlüssel, und ein kurzes Skript in Ihrem Repository statt eines langen Befehls in einem Textfeld.

Und wenn es nicht funktioniert, was es zuerst nicht tun wird, sind die drei Dinge oben die Stellen, an denen ich nachsehen würde. Das Anführungszeichen. Der PATH. Und ob Ihr Werkzeug Ihnen sagen kann, was es getan hat.