Der Traum von Pipes: Das Leben und die Zeit von Yahoo Pipes

• Yahoo Pipes war ein browserbasierter visueller Programmierdienst, den ein kleines Yahoo-Team 2007 entwickelte. Er zog Daten aus RSS-, JSON-, CSV- und Webseitenquellen, filterte, kombinierte und verarbeitete sie und stellte sie dann als neue Feeds oder Datenausgaben bereit.
• Dank eines Modells, bei dem man ohne Code Knoten und Verbindungen zusammensteckte, und einer Pipe-Struktur, die öffentlich, kopierbar und veränderbar war, konnten auch Nichtentwickler Datenflüsse selbst erstellen.
• Für die öffentliche Beta wurden etwa 1.000 Nutzer erwartet, tatsächlich strömten jedoch Hunderttausende herbei. Wegen nicht optimiertem Perl-Code und begrenzter Serverressourcen kam es direkt nach dem Start zu einer massiven Überlastung.
• Pipes verband Strömungen wie Automator, RSS, AJAX, die Mashup-Kultur, Yahoo Maps und YQL, blieb innerhalb der organisatorischen Umbrüche bei Yahoo jedoch ohne Modell zum Verkauf garantierter Aufrufmengen und ohne klare Produktmission vor allem ein Wartungsprojekt.
• Auch nach dem Ende 2015 wirkte es auf Werkzeuge wie Workflow/Shortcuts, Huginn und Node-RED sowie auf Debatten über visuelle Programmierung nach. Heute erschweren jedoch kostenpflichtige APIs, Einschränkungen beim Scraping und urheberrechtliche Unsicherheiten vergleichbare offene Dienste zur Datenkombination.

---

Was Yahoo Pipes möglich machte

• Yahoo Pipes war ein in der Cloud gehosteter Dienst, der verschiedene Datenquellen aus dem Web einbinden ließ, damit Nutzer sie selbst filtern, kombinieren und umwandeln konnten.
• Die möglichen Anwendungen reichten von Alltagsinformationen bis zur Filterung von Nachrichten.
  • Prüfen, ob sich aktuelle Erdbebenmeldungen in der Nähe des Nutzers befinden
  • 100 Nachrichtenseiten bündeln und nur Einträge anzeigen, die Katzen erwähnen
  • Sportergebnisse von Seiten ohne RSS-Feed auslesen
  • Wohnungen auf Craigslist und in anderen Mietlisten finden, die zu Preisvorgaben passen und nahe an Parks liegen
  • Beiträge zu unerwünschten Themen aus bereits abonnierten Medien ausblenden
• Einzelne Pipes waren persönlich und zugleich öffentlich und konnten von anderen Nutzern kopiert und angepasst werden.
• Die Ausgabe konnte als RSS, JSON-Objekt, HTML, KML oder XML erzeugt, in Webseiten eingebettet oder in Datenverarbeitungsabläufe anderer Sites eingespeist werden.

Cloudbasierte visuelle Programmierung aus einem kleinen Team

• Nachdem Pasha Sadri 2006 zu Yahoo zurückgekehrt war, wollte er ein Werkzeug zum Umgang mit Daten bauen, das die neuen Interaktionsmöglichkeiten des Browsers nutzte.
• Pipes war intern bei Yahoo als eine Art Skunkworks-Projekt genehmigt worden, und das Kernteam umfasste einschließlich Sadri fünf Personen.
  • Jonathan Trevor und Ed Ho übernahmen die Programmierung
  • Daniel Raffel war für das Produktmanagement zuständig
  • Kevin Cheng stieß einige Monate später für das Design dazu
• Nutzer erstellten Informationsfeeds, indem sie Elemente im Browser per Drag-and-drop platzierten und mit Linien verbanden.
• Die Datenquellen reichten von Nachrichten und Datenbankausgaben über Blogposts bis zu Atom, RDF, CSV und Webseiten.
• Ergebnisse mit Ortsmarkierungen konnten durch Yahoo-Maps-Filter auf die Nähe zu bestimmten Regionen oder Geländemerkmalen wie Parks eingeschränkt werden.

Öffentlichkeit und Kopierbarkeit als Gestaltungsprinzip

• Das Team machte es zu einem zentralen Gestaltungsprinzip, alle Pipes öffentlich zu halten und jedem das Kopieren und Bearbeiten zu erlauben.
• Sadri sah gerade in dieser Offenheit einen wichtigen Faktor für die Zugänglichkeit für Nichtentwickler.
• Nutzer konnten die Pipes anderer ansehen und daraus lernen; Wissensaustausch war damit direkt in die Nutzung des Dienstes eingebaut.
• Der Name Pipes stammt vom Unix-Konzept der Pipeline, bei der die Ausgabe eines Programms an das nächste weitergereicht wird.

Nachfrageexplosion und Skalierungsprobleme direkt nach dem Start

• Pipes wurde etwa sechs Monate lang von Mitte 2006 bis Anfang 2007 entwickelt und sollte dann im Februar 2007 in eine stille öffentliche Beta gehen.
• Das Team rechnete mit rund 1.000 frühen Nutzern, doch unmittelbar nach dem Start kamen Hunderttausende, und viele konnten gar nicht erst zugreifen.
• Begrenzte Server und nicht optimierter Code konnten weder die Ausführung der Newsfeed-Workflows noch die Auslieferung der Seiten bewältigen, sodass das System komplett überlastet war.
• Eine einzelne Pipe ließ sich damals zwar auch auf privaten oder beruflichen Rechnern ausführen, doch der Betrieb des gesamten Dienstes in großem Maßstab in der Cloud verlangte erhebliche Rechenzentrumsressourcen.
• Bei jedem nicht gecachten Lauf konnte eine einzelne Pipe Dutzende bis Hunderte MB herunterladen; die Bandbreite war damals oft knapp und teuer.
• Sadri erinnerte sich später, die folgenden sechs Monate damit verbracht zu haben, das bereits gebaute System so zu erweitern, dass es mit der Nachfrage Schritt halten konnte.

Das interne Yahoo-Umfeld und Brickhouse

• Sadri arbeitete von 2000 bis 2007 größtenteils bei Yahoo, wechselte 2005 zu Google und wirkte an Google Maps mit, bevor er 2006 zu Yahoo zurückkehrte.
• Yahoos Technology Development Group, kurz TechDev, war als Organisation für Flickr-Mitgründerin Caterina Fake geschaffen worden und war der Yahoo Advanced Development Division unterstellt.
• TechDev sollte neue Richtungen jenseits des Suchgeschäfts erproben und Mitarbeiter mit unternehmerischer Neigung anziehen.
• Fake hatte von Jerry Yang den Auftrag erhalten, Yahoo „mehr wie Flickr“ zu machen, und trieb den Aufbau kleiner, effektiver Teams sowie den Abbau organisatorischer Hürden voran.
• Pipes war eines der ersten Projekte aus diesem Umfeld und wurde später Brickhouse zugeordnet, das in San Francisco aufgebaut wurde.
• Brickhouse galt als eine Art „letzte Station“ für kreative, unruhige Talente, die Yahoo eigentlich verlassen wollten.

Die Erwartungen, die aus Yahoos Größe entstanden

• Yahoo erzielte den Großteil seines Umsatzes mit Suchwerbung und Suchlizenzseiten.
• Laut Kent Brewster verzeichnete die Yahoo-Startseite zur Zeit des Starts von Pipes monatlich 1,2 Milliarden Besuche, und alle Yahoo-Seiten zusammen kamen auf mehr als 1 Milliarde Pageviews pro Tag.
• Nachdem Brewster auf der Yahoo-Startseite einen Link zu Al Gores An Inconvenient Truth vorgeschlagen hatte, war deren Reichweite so groß, dass Al Gore sich bei einer Vorführung nahe der Yahoo-Zentrale persönlich bedankte.
• Zu Sadris Beweggründen für die Rückkehr zu Yahoo gehörte die Erwartung, dass dort zwar nicht so schnell wie bei Google erfolgreiche Projekte entstanden, aber dennoch das „nächste große Ding“ möglich sei.

Von Automator zu einem browserbasierten Werkzeug

• Das grafische Konzept von Pipes war stark von Apples Automator beeinflusst.
• Automator war ein macOS-Werkzeug, mit dem Nutzer Automatisierungen erstellen konnten, indem sie mit Apps oder dem System verknüpfte Aktionen in lineare Workflows zogen.
• Apple stellte Automator 2004 vor, mit dem Ziel, auch allgemeine Nutzer Aufgaben bewältigen zu lassen, für die sonst Programmierkenntnisse nötig waren.
• Pipes entwickelte diese Idee weiter, lief aber nicht als native App, sondern im Browser.
• Automator ließ sich mit verschiedenen auf dem Mac verfügbaren Sprachen und Skripten funktional erweitern, während Pipes als cloudgehosteter Dienst keine Ausführung beliebigen Codes zuließ und nur einen begrenzten Funktionssatz bot.
• In Cloud-Diensten konnte die Ausführung beliebigen Codes damals leicht zu übermäßigem CPU-Verbrauch und Druck auf andere Ressourcen führen.

Die Schwierigkeit der Browser-UI-Umsetzung

• Im Kern war Pipes eine visuelle Programmieroberfläche, in der Knoten und Verbindungsleitungen ohne Code direkt im Browser manipuliert wurden.
• Nachdem Google Maps 2005 Drag, Zoom und Kartenaktualisierung in Echtzeit gezeigt hatte, boten CSS, JavaScript und AJAX eine realistischere Grundlage für Browser-Interaktion.
• Teammitglieder erinnerten sich, dass vor dem Start die meiste Zeit und Arbeit darauf entfiel, die Struktur aus Knoten und Linien zu bauen und als visuelle Coding-Umgebung darzustellen.
• Firefox, Opera, Safari und Internet Explorer unterschieden sich damals stark bei Unterstützung und Verhalten; besonders Internet Explorer hatte eigene Anforderungen an Code und HTML.
• Sadri sah es als eine der wichtigsten technischen Leistungen an, die Kästen und animierten Kurven in mehreren Browsern zum Laufen gebracht zu haben.

Mario Kart und Wii-Farben prägten das Produktdesign

• Das Team spielte jeden Tag nach dem Mittagessen Mario Kart auf dem Nintendo DS und hielt danach Ideen auf dem Whiteboard fest; so liefen Feedback und Diskussionen weiter.
• Raffel hielt diese spielerische, lockere Atmosphäre beim Geben und Empfangen von Feedback für wichtig in der Produktentwicklung.
• Das wiederholte Mario-Kart-Spielen sorgte dafür, dass dem Team helle, kontrastreiche Farbkombinationen im Pipes-Design ständig präsent blieben.
• Nach dem Erscheinen der Nintendo Wii im November 2006 ließ sich das Team auch von deren frühem Farbschema und den weich leuchtenden Farben beeinflussen.
• Apples Aqua-Oberfläche und die mehrfarbigen iMacs dienten ebenfalls als visuelle Bezugspunkte.

Ein Ausführungsmodell, das Datenflüsse sichtbar machte

• Pipes war anfangs linear, entwickelte sich später aber zu einer dynamischeren Struktur, in der jeder Knoten Skripte und Code in der Reihenfolge des Programms ausführen konnte.
• Mit Kontrollstrukturen wie Bedingungen, Schleifen, Verzweigung und Zusammenführung sowie der Ausgabe an externe Webservices waren begrenzte, aber fast allgemein programmierbare Abläufe möglich.
• Es gab auch eine farbliche Syntax für Verbindungen: Grau für Kontrollstrukturen, Blau für Datenfluss.
• Das Team betrachtete Tabellenkalkulationen als wichtigen Maßstab für ein Programmiermodell für Nichtentwickler.
  • In Tabellenkalkulationen sind Daten sichtbar, und Ergebnisse aktualisieren sich sofort bei Änderungen der Eingaben.
  • Fehler lassen sich ohne Kompilieren oder logbasiertes Debugging direkt erkennen.
• Pipes bot reaktive Datenpipelines, die beim Verbinden von Elementen sofort liefen und Ergebnisse zeigten.
• Ein optionaler textbasierter Debugger am unteren Bildschirmrand zeigte die aktuellen Resultate als einzelne Einträge an.
• Sadri sagte, es sei bei Pipes sehr schwer gewesen, ein falsches Programm zu schreiben: Sobald man etwas auf den Bildschirm zog, funktionierte es sofort und erzeugte Ausgabe.

Interne Umsetzung und technische Schulden

• Pipes wurde in schneller Iteration entwickelt, wobei Funktionen, Code und Design fortlaufend bis zu einem noch unklaren Veröffentlichungstermin entstanden.
• Das Team griff teils zu Abkürzungen in der Umsetzung, in der Annahme, später würden sie selbst oder andere alles aufräumen, wenn daraus ein vollständiges Produkt würde.
• Laut Ed Ho war der zugrunde liegende Code größtenteils in Perl geschrieben.
• Perl war weit verbreitet für serverseitige Systeme und Textverarbeitung, reichte aber nicht für den Produktionsmaßstab, den Pipes tatsächlich verlangte.
• Trevor bewertete den Perl-Code als sehr ineffizient und schlecht skalierbar; er sei auf einen schnellen v1-Proof-of-Concept zugeschnitten gewesen.

Lob von O’Reilly und eine explodierende Beta

• Anfang 2007, nach mehreren Monaten Entwicklung ohne festes Enddatum, erhielt das Team von der oberen Führungsebene die Anweisung, Pipes innerhalb von zwei Wochen fertigzustellen.
• Das Team hatte nicht das Gefühl, nur noch zwei Wochen von der Fertigstellung entfernt zu sein, veröffentlichte aber trotzdem.
• Einige Tage vor dem Start nahm Caterina Fake Sadri mit, um Tim O’Reilly eine Demo zu zeigen.
• O’Reilly bezeichnete Pipes als Meilenstein der Internetgeschichte und schrieb, es demokratisiere Webprogrammierung und gebe Nutzern mehr Kontrolle über die Informationsdienste, die sie im Internet konsumieren.
• Dieses Lob ließ das Interesse explodieren, und Sadri erinnerte sich, dass dadurch alle Server praktisch schmolzen.
• Die Nutzung ließ den gesamten Starttag über nicht nach, und das Yahoo-Rechenzentrumsteam stellte Pipes Server zur Verfügung, die eigentlich für andere Gruppen vorgesehen waren.
• Das Team hatte nicht einmal eine Crash-Seite vorbereitet und baute erst nach der Beta eine Seite mit einer Formulierung ähnlich wie „our pipes are clogged“.

Endlos laufende Pipes und Betriebsaufwand

• Nach dem Start begann das Team, die Probleme sichtbar zu machen, die im Tempo der Veröffentlichung unvollendet geblieben waren.
• Wenn Nutzer eine Pipe erstellten, lief sie ohne eigenen Endpunkt weiter.
• Es war kein Login oder manuelles Aktualisieren nötig; RSS-Reader fragten automatisch nach Updates.
• Raffel meinte, dass viele wie „Zombies“ entstandene Jobs schnell Last erzeugten, bei der unklar war, ob sie auf reale Nutzer zurückgingen.
• Yahoo stellte mehr Server bereit, und die Programmierer optimierten den ineffizientesten Code; einige Monate später war die Stabilität verbessert.

Die Stärke als Werkzeug zur Datenkombination

• Pipes wuchs auf dem Nährboden der Mashup-Kultur und der RSS-Hochphase der Mitte der 2000er Jahre.
• RSS wurde als Standard genutzt, um Blogupdates, Podcast-Episoden, Suchergebnisse und andere Informationseinheiten auf einfache, maschinenlesbare Weise zu verteilen.
• Jon Udell meinte, dass Pipes dank RSS weniger Probleme hatte, mit zahllosen Quellen jeweils auf eigene Weise sprechen zu müssen, weil der Zugriffsweg standardisiert war.
• Pipes verarbeitete nicht nur RSS, sondern auch Atom, RDF und CSV; mit etwas Aufwand konnte es auch Webseiten abrufen und bestimmte Daten daraus herausfiltern.
• Es war auch mit internen Yahoo-Diensten verbunden, insbesondere mit Flickr, und unterstützte später zudem Yahoo Query Language, also YQL.
• YQL war ein unternehmensweites Projekt, das internen Yahoo-Produkten und externen Entwicklern das Abfragen über einen gemeinsamen Endpunkt ermöglichen sollte.
• Pipe-Ausgaben konnten in Seiten eingebettet oder als HTML, JSON, KML, RSS oder XML erzeugt werden.
• Externe Webseiten konnten Pipe-Workflows auch per JavaScript abfragen und Ergebnisse abrufen.

Der Fall der Craigslist-Sperre

• Pipes war nützlich, konnte aber auch andere Sites belasten.
• Craigslist sperrte Pipes 2009, nachdem ein Entwickler außerhalb von Yahoo Pipes zum Bau einer Karte von Craigslist-Mietangeboten verwendet hatte.
• Der CEO von Craigslist behauptete, Pipes verbrauche zu viele Ressourcen.
• Durch die Sperre verloren zahlreiche Mashups im Internet ihre Datenquelle; einige Entwickler behielten ihre Pipes bei, nutzten Craigslist aber nicht mehr als Quelle.
• Rund zwei Wochen später wurde die Sperre wieder aufgehoben.

Fehlendes Geschäftsmodell und fehlende organisatorische Unterstützung

• Der Niedergang von Pipes begann schon beim Start; um vom Konzept zu einem ausgereiften Produkt zu werden, hätte es ein größeres Team und eine klarere Mission gebraucht.
• Kent Brewster sagte, dass Menschen auf Konferenzen Pipes zwar beeindruckend fanden, Yahoo aber auf die Frage, wie viel man für den Dienst bezahlen könne, antworten musste, man sei noch nicht an diesem Punkt.
• Es gab kein Angebot, garantierte monatliche Pipe-Aufrufmengen zu kaufen; unter solchen Bedingungen war es für Fachleute oder Großunternehmen schwer, zu investieren.
• Yahoo entließ im Januar 2008 rund 1.000 Mitarbeiter und lehnte später das Übernahmeangebot von Microsoft über 44,6 Milliarden Dollar in bar und Aktien ab.
• Später im selben Jahr wurden weitere 10 % der Belegschaft entlassen, also etwa 1.500 Personen.
• Von 2008 bis zum Verkauf und der faktischen Zerschlagung 2017 war das auffälligste Ereignis in Yahoos Finanzgeschichte, dass Marissa Mayer 2012 dem Verkauf von Alibaba-Anteilen zustimmte.
• Yahoo hatte 2005 für 1 Milliarde Dollar Anteile an Alibaba erworben; zum Zeitpunkt des Verkaufs war ihr Wert auf 7,6 Milliarden Dollar gestiegen.

Brickhouse und die Auflösung des Teams

• Brickhouse brachte 2007 mehrere Projekte hervor, die in Technikmedien Aufmerksamkeit bekamen.
  • BravoNation: ein Online-System zum Austauschen von Anerkennung
  • FireEagle: ein Dienst, der Standortinformationen bereitstellte und dabei Privatsphäre vermittelte
  • KickStart: eine Jobvermittlungsseite für Studierende
  • Yahoo Live: ein früher Dienst für Live-Webcam-Streaming
• Diese Projekte führten jedoch nicht zu Erfolgen.
• Fake ging ab April 2007 in Schwangerschafts- und Mutterschaftsurlaub und verließ Yahoo im Juni 2008.
• Bradley Horowitz wechselte im Februar 2008 zu Google, Salim Ismail ging im März 2008.
• Auch Chad Dickerson verließ Yahoo etwa zur Mitte des Jahres 2008, ähnlich wie Fake.
• Brickhouse wurde Ende 2008 geschlossen.
• Auch das Pipes-Team zerstreute sich: Einige verließen Yahoo, andere wechselten in andere Teams, und die Betreuung des Dienstes ging an internes Verwaltungspersonal über.

Warum Pipes lange überlebte und wie es endete

• Sadri gründete einige Monate nach dem Start von Pipes Polyvore.
• Polyvore war eine Plattform, auf der Nutzer Bildcollagen teilen konnten, und wurde oft für Mode und Inneneinrichtung verwendet.
• Polyvore wurde 2015 von Yahoo übernommen; Sadri ist inzwischen bei Sutter Hill Ventures.
• Auch Ho ging ungefähr zur gleichen Zeit wie Sadri, und Cheng sowie Raffel verließen das Unternehmen innerhalb eines Jahres nach dem Start von Pipes.
• Trevor blieb bis 2010 bei Yahoo, wechselte durch mehrere Teams und nahm Pipes mit, was dem Dienst laut seiner Aussage ein längeres Leben ermöglichte.
• Trevor schrieb Pipes von Perl in Java neu und machte es mit der internen YQL-Sprache kompatibel.
• Danach sei im Grunde nur noch die Frage geblieben, wann der Dienst abgeschaltet würde.
• Yahoo stellte Pipes 2015 endgültig ein.
• Im Hacker-News-Thread zur Abschaltung suchten Nutzer weiterhin nach Alternativen und beklagten das ungenutzte Potenzial.
• Sadri schrieb damals: „Ich wünschte, Pipes wäre im Zeitalter von Containern wie Docker gestartet worden“, und ergänzte, es habe Ideen für One-Click-Deployment von dem gegeben, was man heute Container nennen würde.

Einfluss auf spätere Werkzeuge und visuelle Programmierung

• Pipes inspirierte eine Generation von Programmierern, UI-Designern und Produktverantwortlichen.
• Die iPhone/iPad-Automatisierungs-App Workflow, die Apple 2017 übernahm, wurde später eingestellt und integriert und dann als Shortcuts für iOS, iPadOS und macOS neu ausgeliefert; sie wird als eines der Pipes ähnlichen Werkzeuge genannt.
• Andrew Cantino, der Huginn entwickelte, schrieb 2021 auf Hacker News, dass Yahoo Pipes ihn bei der Entwicklung von Huginn inspiriert habe.
• Node-RED erschien 2013 und wird als Werkzeug mit einer ähnlichen Atmosphäre wie Pipes genannt.
• Die Zahl öffentlicher und nicht öffentlicher Werkzeuge, die als Pipes-Alternativen gelten, nahm weiter zu.
• Ein Nutzer im Hacker-News-Thread zur Abschaltung berichtete, Pipes sei die Grundlage eines Kurses über Daten-Mashups gewesen, und Studierende ohne Entwicklungserfahrung hätten innerhalb weniger Stunden kleine maßgeschneiderte Daten-Apps bauen können.
• Dazu gehörte etwa das Geokodieren eines Blogs über Street Art mittels Extraktion von Ortsentitäten und die Ausgabe des angereicherten Feeds in einer Kartenansicht.

Warum ein ähnlicher Dienst heute schwerer zu bauen ist

• Greg Wilson sagte, visuelle Programmierwerkzeuge seien in vielen Berufen und Branchen als spezialisierte Tools weit verbreitet, und selbst hochwertige Animationen in Hollywood entstünden mit Werkzeugen, die wie Yahoo Pipes Datenflussblöcke verbinden.
• Auch MATLAB wurde als Plattform für mathematische Modellierung erwähnt, mit weltweit etwa 4 Millionen Nutzern, von denen viele visuelle Programmierschnittstellen verwenden.
• Einer der Gründe, warum sich allgemeine grafische Werkzeuge nicht breit durchgesetzt haben, ist die urheberrechtliche Unsicherheit.
• In einem Kommentar zu O’Reillys Pipes-Artikel von 2007 schrieb Anil Dash, es sei unklar, ob das Vorhandensein eines Feeds Abonnement, häufiges Polling und erneute Veröffentlichung stillschweigend erlaube.
• Auch 16 Jahre später sind diese Fragen nicht eindeutig geklärt, und das Risiko von Klagen kann Unternehmen abschrecken, die kostenlose oder kostenpflichtige Dienste bauen wollen.
• Das heutige Internet hat mehr frei zugängliche Informationsfeeds abgeschottet, und auch Scraping, also das Abrufen gewöhnlicher Webseiten mit anschließendem Parsen der Daten, wird stärker eingeschränkt.
• Sadri sagte, viele legitime APIs seien zu kommerziellen APIs hinter Bezahlschranken geworden.
• Trotzdem ist die Zuneigung zu Pipes geblieben, und Sadri sagte, er denke darüber nach, ob sich mit heutiger Infrastruktur eine nächste Generation wie „Pipes 2“ bauen ließe.

[GN⁺]

Hacker-News-Kommentare

• Als Retool-Mitarbeiter habe ich an diesem Beitrag gearbeitet; dies ist der zweite Teil einer regelmäßigen Reihe über neue Programmierumgebungen, die Entwickler stark beeinflusst haben.
  Solche Beiträge entstehen mit viel Liebe, und es ist großartig, direkt mit den ursprünglichen Teams sprechen zu können, die Produkte geschaffen haben, die uns geprägt haben.
  Einer der spannendsten Aspekte beim Bau eines Produkts wie Retool ist die Weiterentwicklung früherer Ideen, und in alten Computer-Fachartikeln und Produkten stecken viele großartige Ideen, die ihrer Zeit voraus waren oder im Wandel der Branche verschwanden.
  Pipes war ein Bezugspunkt beim Bau unseres neuen Produkts Retool Workflows, und es gibt noch viele weitere Ideen für Programmierumgebungen, die wir behandeln könnten; wenn ihr aber eine Umgebung habt, zu der ihr eine besondere Bindung habt, lasst es uns wissen.
  Der erste Deep-Dive-Artikel war über Visual Basic: https://retool.com/visual-basic
  Retool Workflows: https://retool.com/workflows

  • Der künstlerische Ansatz ist schön, aber auf Firefox 120 unter Linux 6.6 funktioniert die Seite fast gar nicht.
    Insgesamt ruckelt es stark und das Scroll-Hijacking ist heftig; in Chromium läuft es deutlich flüssiger, aber das Scroll-Hijacking ist immer noch schlimm.
    Normalerweise würde ich Linux nicht als besonders wichtige Zielplattform sehen, aber bei Inhalten rund ums Programmieren kann das anders sein.
  • Ich frage mich, ob es Hinweise auf den nächsten Teil gibt. Vielleicht Smalltalk, HyperCard oder NeXTSTEP Interface Builder?
  • Als Autor des Originalartikels vielen Dank für die wirklich tolle Arbeit. Ich suche immer noch nach weiteren Easter Eggs.
    Anderen Lesern würde ich empfehlen, auf dem Desktop im Startbildschirm alles anzuklicken.
  • Gibt es einen RSS- oder JSON-Feed, den man nur für diese Reihe abonnieren kann? Falls nicht, wäre zumindest eine Webseite schön, die alle Teile sammelt.

• Meine liebste Technik für Projektübersicht bei der Arbeit war Pipes, und ich habe seitdem nichts gefunden, das so schnell war.
  Ich habe mit Yahoo Pipe 10–15 Jira-Projekte und 30–50 GitHub-Commit-Streams zusammengeführt, dedupliziert und in einen einzigen RSS-Feed verwandelt, den ich dann in Google Reader gelesen habe.
  So konnte ich schnell sehen, wer wann wo was geändert hat, und weil es RSS war, musste ich mich weder durch E-Mails wühlen noch mehrere Benachrichtigungsseiten prüfen.

• Ich vermisse Yahoo Pipes und YQL sehr.
  2009 habe ich auf jQuery aufbauend im Grunde ein Cross-Domain-XHR-(AJAX)-Plugin gebaut, mit dem man clientseitig beliebige Webseiten abrufen und mit aus CSS-Selektoren umgewandeltem XPath abfragen konnte.
  Das war die Zeit, in der YQL JSONP zurückgab und sich alles magisch anfühlte.

  • Du solltest dir Node-RED ansehen. Es bietet alles, was Ypipes konnte, und noch mehr.
    Außerdem ist ein Pluspunkt, dass die UI jQuery verwendet.
    Es wird zwar für IoT vermarktet, ist aber sehr flexibel und kann fast alles.
    https://nodered.org
  • Pipes konnte man wie einen CORS-Proxy verwenden.
    Damals habe ich nur mit jQuery eine Client-App ähnlich wie Spotify gebaut, die MP3s von radioblogclub und VK.com suchte und streamte und Metadaten sowie ähnliche Empfehlungen von last.fm holte.

• Das ist die ruckeligste Animation, die ich je gesehen habe. In Chrome auf Android, auf einem Pixel 7, ist sie völlig unbenutzbar; gibt es eine Textversion?

  • Auch in Chrome auf einem M1 Pro ist sie völlig unbenutzbar.
    Alle Chrome-Fenster werden unbenutzbar, sobald dieser Seitentab sichtbar ist.
  • Wurde oben schon erwähnt, aber ich ergänze es noch einmal: In Firefox auf einer Linux-Workstation ist es wirklich schlimm.
    In Chromium ist es viel besser, aber das Scroll-Hijacking ist weiterhin heftig.
  • Auch auf einem M3 Pro mit 64 GB und Safari auf aktuellem macOS völlig unbenutzbar.
  • Ich dachte, die Seite sei eingefroren, und habe nichts richtig zum Laufen bekommen.
  • Auf iOS ruckelt es, zoomt leicht hinein, bricht dann auseinander und wird zu einer großen weißen, scrollbareren Seite.
    Wenn es richtig funktionieren würde, wäre die Animation wohl ziemlich cool, aber schade, dass so viel Aufwand betrieben wurde, nur um Leser abzuschrecken.

• Ich möchte mein Lieblings-Tool zur Workflow-Automatisierung aus jüngerer Zeit empfehlen, dessen Name ähnlich klingt: Pipedream: https://pipedream.com/
  Wenn du nach Automatisierung im Stil von Yahoo Pipes suchst, ist es definitiv einen Versuch wert.
  Ich habe keinerlei Verbindung dazu und bin nur ein zufriedener Nutzer.

  • Ich habe mich gerade angemeldet; es scheint einige Docker-Container ersetzen zu können, die ich auf dem kostenlosen Tier von fly.io laufen lasse und in die ich Daten über das kostenlose Tier von Supabase einspeise.
  • Der Eigentümer tod sacerdoti nutzt es als Karma-Arbitrage-Pumpe, indem er beliebte Posts von lobste.rs abschöpft und bei HN einreicht.
    Wenn du sehen willst, was ich meine, suche auf https://gerikson.com/hnlo/ nach todsacerdoti.
    Wenn man sieht, wie viel HN-Karma damit aufgebaut wurde, scheint es ziemlich gut zu funktionieren.
  • https://windmill.dev ist eine selbst hostbare Open-Source-Alternative zu pipedream.
    Zur Transparenz: Ich bin der Gründer.
  • Kann man es selbst hosten?

• Das diese Woche veröffentlichte Open-Source-Cloud-Scripting-Engine Flowpipe könnte ebenfalls interessant sein.
  Damit kann man Pipelines in HCL erstellen, um HTTP-Anfragen zu verketten, Container auszuführen, Lambda-kompatible Funktionen laufen zu lassen, Datenbanken abzufragen und mehr — auf dem eigenen Rechner und über die CLI.
  Es lässt sich auch mit dem Open-Source-Projekt Steampipe kombinieren, das Cloud-Ressourcen per SQL abfragt, und es gibt mehr als 139 Plugins.
  Wir fokussieren uns stärker auf DevOps, aber auch Yahoo Pipes war eine Inspiration dafür, solche Dinge „pipes“ zu nennen.
  https://github.com/turbot/flowpipe
  https://github.com/turbot/steampipe

  • Ich mag Steampipe. Es macht es einfach, zu vielen Cloud-Ressourcen auf schlichte und klare Weise Feedback zu bekommen.
    select * from cloud ist eine gute Zusammenfassung, und ich werde mir Flowpipe auch ansehen.

• Im Studium habe ich Pipes verwendet, um die Reihenfolge für die Zimmerwahl im Wohnheim zufällig festzulegen.
  Ich habe die Top-Schlagzeilen der NY Times abgerufen, gehasht und daraus deterministisch eine Zahl zwischen 1 und 6 erzeugt.
  Im Sommer, als wir räumlich getrennt waren, war das der beste Weg, alle von der Fairness zu überzeugen, ohne selbst Code ausführen zu müssen, und es war nützlich und unterhaltsam.

• Pipes war definitiv großartig.
  Es passte perfekt in die goldene Web-2.0-Zeit, als dank weit verbreiteter Technologien wie RSS noch lose und offene Interoperabilität existierte.
  Es war effektiv darin, einfache Dinge zu verknüpfen, um etwas Einfaches, aber Nützliches zu schaffen.
  Gleichzeitig fragt man sich bei diesem Deep-Dive-Artikel mit seinem enormen Design- und Arbeitsaufwand schon, was das eigentlich sein soll. Retool hat sich wirklich Mühe gegeben, und man fragt sich fast, warum sie so etwas nicht schon früher gemacht haben.

• Ich finde es interessant, wie solche Beiträge produziert werden.
  Es steckt viel Sorgfalt darin, und es hat offensichtlich einiges an Zeit gekostet, bis zum Endergebnis alles ausgearbeitet war. Hochwertige Inhalte und Feinschliff bedeuten schließlich hohe Kosten.
  Trotzdem ist mir der Zweck noch nicht ganz klar. Es wirkt nicht wie ein Marketingartikel, aber zwischen den Zeilen liest es sich klar als Wenn dir Pipes gefallen hat, wird dir Retool wahrscheinlich auch gefallen.

  • Ich lese es gerade und habe genau dieselbe Frage.
    Die Produktionsqualität ist hoch, und auch die URL retool.com/pipes wirkt nicht wie ein gewöhnlicher Blogpost.

• Ich habe eine Weile gebraucht, um zu erkennen, dass AWS Step Functions Yahoo Pipes ähnelt.
  Es ist nicht ganz so einfach und hat auch nicht so viele anklickbare Bausteine, aber trotzdem war es seltsam, dass mir das so spät aufgefallen ist.
  Vielleicht kann jemand mit mehr Einsicht erklären, wo dieser Vergleich nicht passt.