KI-Tools zwischen Uber-Fahrten entwickeln: Wie ich tote Zeit in Entwicklungsgold verwandelte
Hallo, mein Name ist Chris. Ich bin ein ehemaliger Handwerker, der hier in Vancouver zum Mitfahrgelegenheitsfahrer wurde, und ich bin auf etwas ziemlich Unglaubliches gestoßen. In der eineinhalb Stunden, die ich täglich zwischen den Fahrten im Durchschnitt habe, bringe ich mir selbst bei, KI-gestützte Anwendungen auf meinem Handy zu entwickeln. Was ich in diesen verstreuten Momenten der Leerlaufzeit erreicht habe, ist ehrlich gesagt überraschend – selbst für mich.
Ich habe das Handwerk nicht freiwillig aufgegeben. Eine Kreissäge hat mir den größten Teil meines Daumens abgenommen, und das war's. Über zwanzig Jahre als Maler, Klempner und Tischler, und ein schlechter Moment beendete alles. Ich werde nicht so tun, als wäre ich nicht eine Weile verbittert gewesen. Aber hier ist die Sache mit dem Handwerker – selbst wenn sich die Werkzeuge ändern, die Problemlösungsmentalität bleibt. Wenn du auf ein Hindernis stößt, wartest du nicht darauf, dass jemand anderes es behebt. Du baust eine Lösung.
Diese Denkweise hat sich perfekt auf die Softwareentwicklung übertragen, auch wenn ich zugebe, dass sie mit Kompromissen verbunden ist. Wann immer ich auf ein Hindernis in meiner Codierungsreise stoße – und glauben Sie mir, ich stoße regelmäßig darauf – baue ich ein Werkzeug um das Problem herum. Es ist, als ob ich auf einen Fluss stoße, den ich nicht überqueren kann, dann baue ich einfach eine Brücke. Und dieser Ansatz war absolut befreiend, auch wenn manchmal ein monatliches Abonnement dasselbe Problem effizienter gelöst hätte.
Die Handwerkermentalität: Problemlösung im Code
Die Parallelen zwischen handwerklicher Arbeit und Softwareentwicklung gehen tiefer, als man erwarten würde. In der Tischlerei, wenn dir eine bestimmte Schablone fehlt, baust du eine aus Holzresten. In der Klempnerei, wenn du den richtigen Adapter nicht findest, fertigst du eine provisorische Kupplung an. Diese Art von Bastelei – mit verfügbaren Materialien Lösungen zu schaffen – wird zur zweiten Natur.
Aber Softwareentwicklung fügt Ebenen der Komplexität hinzu, die physische Handwerke nicht haben. Wenn ein Tischler eine Schablone baut, funktioniert sie entweder oder nicht. Wenn sie bricht, ist das offensichtlich. Wenn ich eine benutzerdefinierte Anwendung baue, sind die Fehlermodi heimtückischer. Ein nicht behandelter Randfall könnte stillschweigend eine Verbindung abbrechen, eine Abhängigkeit könnte eine Schwachstelle aufweisen, die monatelang unbemerkt bleibt, und der Code selbst wird zu einem Risiko, das ständige Aufmerksamkeit erfordert.
Die Romantik des Bauens eigener Werkzeuge ist jedoch real. Es ist zutiefst befriedigend, eine Lösung zu entwickeln, die genau zu deinem Arbeitsablauf passt, optimiert für deine spezifischen Bedürfnisse, und nicht für die Annahmen eines Produktmanagers darüber, was Benutzer wollen. Die Frage, mit der ich mich ständig auseinandersetze, ist: Wann dient dieser Ansatz der Produktivität und wann wird er zu Overengineering im Gewand der Problemlösung?
Die erste Brücke: Mein eigener SSH-Client
Meine Flaggschiff-Kreation ist eine iOS-App, die ich Terms nenne – derzeit in der vierten Iteration. Dieser SSH-Client hat sich über Jahre der realen Nutzung in diesen verstreuten Momenten zwischen den Fahrten entwickelt und ist perfekt auf meinen einzigartigen Copy-Paste-, Sprach-zu-Text-, KI-gesteuerten Codierungsarbeitsablauf zugeschnitten.
Die App verwendet biometrische Authentifizierung – genauer gesagt Face ID. Wenn ich sie öffne, authentifiziert das System mein Gesicht und bringt mich direkt in meine VPS-Hosting-Umgebung, direkt an der Befehlszeile. Die Technologie hinter Face ID ist faszinierend: Apples TrueDepth-Kamerasystem projiziert über 30.000 unsichtbare Punkte, um eine präzise Tiefenkarte Ihres Gesichts zu erstellen, und verwendet Infrarotbildgebung, um auch im Dunkeln zu funktionieren.
Die Fähigkeit, bequem auf meinem Handy zu sitzen, Werkzeuge zu bauen, die echtes Potenzial haben, während ich ständig Fehler behebe und optimiere – es ist eine echte Freude. Ich kann es nur empfehlen. Und ja, es hat etwas still Befriedigendes an sich, dass dieselben Hände, die früher Wände gerahmt und Kupferrohre gelötet haben, jetzt Python auf einen Linux-Server von einem Parkplatz in Vancouver aus bereitstellen.
Eines meiner Lieblingsfeatures adressiert eine häufige Frustration in mobilen Entwicklungsumgebungen. Wenn ich auf einen Fehler oder einen Traceback stoße, der das Terminal einfriert, wische ich einfach nach oben, um die App zu schließen, öffne sie erneut, lasse Face ID mich wieder authentifizieren, und ich bin sofort wieder an der Befehlszeile, bereit fortzufahren. Dieser nahtlose Wiederherstellungsprozess hat mir unzählige Stunden der Frustration erspart und hält meinen Schwung während dieser kostbaren Codierungssitzungen zwischen den Fahrten aufrecht.
Die technische Implementierung basiert auf der Speicherung verschlüsselter SSH-Schlüssel in der iOS-Keychain, die auf Geräten mit einer Secure Enclave hardwaregestützte Sicherheit bietet. Das Verbindungszustandsmanagement war einer der kniffligsten Teile, um es richtig hinzubekommen – die Handhabung von Netzwerkübergängen, während ich mich zwischen verschiedenen Mobilfunkmasten und WLAN-Hotspots in der Stadt bewege. Ich habe eine Verbindungspersistenzschicht implementiert, die Netzwerkänderungen erkennen und automatisch wieder mit der entfernten Sitzung verbinden kann, oft so nahtlos, dass ich gar nicht bemerke, dass der Übergang stattgefunden hat.
Hätte ich mit vorhandenen SSH-Clients ähnliche Funktionen erreichen können? Absolut. Aber diese Apps sind auf allgemeine Anwendungsfälle optimiert, während meine auf meinen spezifischen Arbeitsablauf fokussiert ist. Die benutzerdefinierten Tastaturkürzel, die Integration mit iOS' Sprach-zu-Text für Codierung per Sprache und das spezialisierte Zwischenablage-Management für das Austauschen von Code-Snippets zwischen meinem Telefon und Server – diese Funktionen existieren, weil ich sie für meine genauen Bedürfnisse gebaut habe.
Die Video-zu-Audio-Brücke: Reibung im Content-Workflow lösen
Das zweite große Werkzeug, das ich entwickelt habe, entstand aus einem spezifischen Reibungspunkt in meinem Content-Erstellungs-Workflow. Ich brauchte eine zuverlässige Möglichkeit, Videos zu transkribieren, und obwohl es Webdienste gibt, die das erledigen, benötigte ich etwas Flexibleres für meine persönliche Content-Bibliothek.
Mein Ansatz war, Videos zuerst in Audio umzuwandeln – ein viel leichterer Prozess als das Hochladen großer Videodateien. Jahrelang verließ ich mich auf eine Drittanbieter-App dafür, aber wenn iOS-Updates sie kaputt machten oder ich bestimmte Audioformate benötigte, war ich aufgeschmissen. Also baute ich meinen eigenen Konverter.
Die zugrundeliegende Technologie basiert auf FFmpeg, einem leistungsstarken Open-Source-mu
Get new posts
Subscribe in your language
New posts delivered to your inbox. Unsubscribe anytime.
Receive in: