パイプの夢: Yahoo Pipesの生涯と時代
(retool.com)- Yahoo Pipesは2007年にYahooの小規模チームが作ったブラウザベースの視覚的プログラミングサービスで、RSS・JSON・CSV・Webページのデータを取り込み、フィルタリング・結合・加工して、新しいフィードやデータ出力として配信できるようにした
- コードを書かずにノードと線をつなぐ方式と、公開・複製・修正可能なPipe構造により、非開発者でもデータフローを自分で作れた
- 公開ベータは約1,000人規模を想定していたが、実際には数十万人が押し寄せ、最適化されていないPerlコードと限られたサーバー資源のため、公開直後に大規模な過負荷が発生した
- PipesはAutomator、RSS、AJAX、mashup文化、Yahoo Maps、YQLといった流れを組み合わせたが、保証された呼び出し量を販売するモデルや明確な製品ミッションがないまま、Yahooの組織変化の中で保守中心の存在にとどまった
- 2015年の終了後も、Workflow/Shortcuts、Huginn、Node-REDのようなツールや視覚的プログラミングの議論に影響を残したが、今日では有料API、スクレイピング制限、著作権の不確実性により、同様のオープンなデータ結合サービスは作りにくくなっている
Yahoo Pipesで可能だったこと
- Yahoo PipesはWeb上の複数のデータソースを取り込み、ユーザーが自分でフィルタ・組み合わせ・変換できるクラウドホスティングサービスだった
- ユーザーが作れた処理は、生活情報からニュースのフィルタリングまで幅広かった
- 最新の地震記録が自分の近くかどうかを確認する
- 100のニュースサイトを集めて、猫に言及した項目だけを見る
- RSSフィードのないサイトからスポーツのスコアを取得する
- Craigslistや他の賃貸リストから、価格条件と公園の近くという条件に合うアパートを探す
- すでに購読している媒体から、関心のない話題の記事を除外する
- 個々のPipeは個人用でありながら公開されており、他のユーザーがコピーして修正できた
- 出力はRSS、JSONオブジェクト、HTML、KML、XMLなどにでき、Webページへ埋め込んだり、他サイトのデータ処理フローへつないだりすることもできた
小さなチームが作ったクラウドベースの視覚的プログラミング
- Pasha Sadriは2006年にYahooへ戻った後、ブラウザの新しい相互作用の可能性を生かして、データを扱うツールを作ろうとした
- PipesはYahoo内部で承認されたスカンクワークス的なプロジェクトで、コアチームはSadriを含めて5人規模だった
- Jonathan TrevorとEd Hoがプログラミングを担当
- Daniel Raffelはプロダクトマネジメントを担当
- Kevin Chengは数か月後にデザインへ参加
- ユーザーはブラウザ上で要素をドラッグ＆ドロップし、線でつないで情報フィードを作成した
- データソースはニュース、データベース出力、ブログ記事、Atom、RDF、CSV、Webページなどへ広がっていった
- 位置タグ付きの結果はYahoo Mapsのフィルタを通して、特定地域や公園のような地形要素への近接性で絞り込めた
公開と複製が設計原則になった
- チームはすべてのPipeを公開し、誰でもコピーして修正できるようにすることを中核的な設計原則にした
- Sadriは、この公開性が非開発者のアクセス性を高めるうえで重要な役割を果たしたと見ていた
- ユーザーは他人のPipeを見て学ぶことができ、知識共有がサービスの使い方そのものに組み込まれていた
- Pipesという名前は、あるプログラムの出力を次のプログラムへ渡すUnixのパイプライン概念に由来する
公開直後に噴き出した需要と拡張問題
- Pipesは2006年半ばから2007年初めまで約6か月開発された後、2007年2月に静かな公開ベータとして出す予定だった
- チームは初期ユーザーを約1,000人と見込んでいたが、公開直後に数十万人が押し寄せ、アクセスできなかったユーザーも多かった
- 限られたサーバーと最適化されていないコードでは、ニュースフィードのワークフロー実行とページ配信を支えきれず、システムは完全に過負荷になった
- 単一のPipeは当時の個人用・業務用コンピュータでも実行できたが、サービス全体をクラウドで大規模運用するには相当なデータセンター資源が必要だった
- キャッシュされていない実行ごとに、単一のPipeが数十MBから数百MBをダウンロードすることもあり、当時は帯域が不足し、コストも高い場合が多かった
- Sadriは、その後の6か月を、すでに作ったシステムを拡張して需要に追いつくことに費やしたと振り返っている
Yahoo内部環境とBrickhouse
- Sadriは2000年から2007年までの大半をYahooで過ごし、2005年にはGoogleへ移ってGoogle Mapsに参加した後、2006年にYahooへ戻った
- YahooのTechnology Development Group、すなわちTechDevは、Flickr共同創業者Caterina Fakeのために作られ、Yahoo Advanced Development Divisionの下に置かれていた
- TechDevは、検索事業に縛られない新しい方向性を試し、起業家的な気質の社員を引きつける役割を担っていた
- FakeはJerry YangからYahooを「Flickrのように」するよう委ねられ、小さく効果的なチームを作り、組織の壁を減らす施策を進めた
- Pipesはその流れから生まれた最初期のプロジェクトの一つで、その後San Franciscoに作られたBrickhouseの傘下に入った
- Brickhouseは、Yahooを去ろうとしていた創造的で不安定な人材にとって「最後の停車駅」のように見なされていた
Yahooの規模が生んだ期待感
- Yahooは検索広告と検索ライセンスサイトから売上の大半を得ていた
- Kent Brewsterによれば、Pipes公開時のYahooホームページは月間12億訪問を記録し、Yahoo全体のサイトは1日10億ページビュー以上を受けていた
- BrewsterがYahooホームページにAl Goreの An Inconvenient Truth へのリンク掲載を提案した後、Al GoreがYahoo本社近くの上映会で直接感謝を伝えるほど、ホームページ露出の影響力は大きかった
- SadriがYahooへ戻った背景には、当時Googleほど速く成功プロジェクトを出せてはいなかったものの、Yahooにも「次の大きなもの」が生まれる可能性があるという期待があった
Automatorからブラウザベースのツールへ
- Pipesのグラフィカルな概念はAppleのAutomatorから大きな影響を受けていた
- Automatorは、ユーザーがアプリやシステムに接続された操作を線形ワークフローへドラッグ＆ドロップして自動化を作れるmacOSツールだった
- Appleは2004年にAutomatorを公開し、コーディングスキルが必要な作業を一般ユーザーでも扱えるようにすることを目指していた
- PipesはAutomatorの発想を発展させたが、ネイティブアプリではなくブラウザで動作した
- AutomatorはMacで利用できる複数の言語やスクリプトで機能拡張できたが、Pipesはクラウドホスティングサービスだったため、任意コードの実行を許可せず、限定された機能セットだけを提供した
- 当時のクラウドサービスで任意コードを実行可能にすると、CPU資源を過剰消費し、他の資源にも圧力をかける恐れがあった
ブラウザUI実装の難しさ
- Pipesの中核は、コードを書かずにノードと接続線をブラウザ内で操作する視覚的プログラミングUIだった
- Google Mapsが2005年にドラッグ・ズーム・リアルタイム地図更新を示して以降、CSSとJavaScript、AJAXを使ったブラウザ上のインタラクションがより現実的な基盤になった
- チームメンバーは、公開前に最も多くの時間と労力を、ノードと線の構造を作り、それを視覚的コーディング環境として表現することに費やしたと振り返っている
- 当時のFirefox、Opera、Safari、Internet Explorerは対応水準や挙動が異なり、特にInternet Explorerは独自のコーディング・HTML要件を持っていた
- Sadriは、ボックスとアニメーション曲線を複数ブラウザで動かしたことが主要な技術的成果の一つだったと見ていた
Mario KartとWiiの色彩が製品デザインに残したもの
- チームは昼食後、毎日Nintendo DSでMario Kartをプレイし、その後にホワイトボードへアイデアを整理する形でフィードバックと議論を続けていた
- Raffelは、ゲームをしながら楽しい雰囲気でフィードバックを交わすことが製品開発に重要だったと考えていた
- 繰り返しMario Kartを遊んだことで、明るくコントラストの強い配色をPipesのデザインで常に意識するようになった
- 2006年11月にNintendo Wiiが登場した後、チームは初期Wiiの色彩体系と柔らかく光るような色味からも影響を受けた
- AppleのAquaインターフェースや多色iMacも視覚的な参考点だった
データフローを見える化した実行モデル
- Pipesは初期には線形フローだったが、その後、各ノードがプログラム順序の中でスクリプトやコードを実行できる、より動的な構造へ発展した
- 条件分岐、反復、分岐と結合、外部Webサービスへの出力受け渡しといった制御構造を提供し、限定的ながら汎用プログラミング言語に近い作業を可能にした
- 制御構造の線を灰色、データフローを青で示すリンク構文の色分けも用いられた
- チームは、スプレッドシートを非開発者向けプログラミングモデルの重要な基準と見なしていた
- スプレッドシートではデータが見え、入力の変化に応じて即座に結果が更新される
- コンパイルやログベースのデバッグなしに、問題箇所をすぐ確認できる
- Pipesは、要素をつなぐと即時に実行され結果を表示する、反応的なデータパイプラインを提供した
- 画面下部の任意表示のテキストデバッガは、現在の結果を個別項目として表示した
- Sadriは、Pipesでは誤ったプログラムを書くのが非常に難しく、何かを画面上にドラッグすればすぐ動いて出力が得られたと語っている
内部実装と技術的負債
- Pipesは高速に反復開発され、定まっていない公開時期に合わせて機能・コード・デザインが作られ続けた
- チームは、後に完全な製品になれば自分たちや他の人が整理できるだろうと考え、近道の実装を使うこともあった
- Ed Hoによれば、基盤コードの大半はPerlで書かれていた
- Perlはサーバーサイドシステムやテキスト処理で広く使われていたが、Pipesが実際に要求するようになった本番規模には不向きだった
- Trevorは、Perlコードは非常に非効率で拡張性に乏しく、素早いv1の概念実証向けの設計だったと評価した
O’Reillyの高評価と爆発的ベータ
- 2007年初頭、明確な終了地点なしに数か月開発を続けていたチームは、上級管理職から2週間以内にPipesを完成させるよう指示された
- チームは、完成まで2週間という状態ではないと感じていたが、結局公開した
- 公開の数日前、Caterina FakeはSadriを連れてTim O’Reillyにデモを見せた
- O’ReillyはPipesをインターネット史の画期的な出来事と評価し、Webプログラミングを民主化し、ユーザーが消費するインターネット情報サービスをよりよく制御できるようにすると書いた
- この高評価が関心を爆発させ、Sadriはサーバーが完全に溶け落ちたようだったと振り返っている
- 公開日を通して利用量は減らず、Yahooのデータセンターチームは他グループに割り当てる予定だったサーバーをPipesへ回した
- チームはクラッシュページすら用意しておらず、ベータ後に「our pipes are clogged」に近い文言のページを先に作った
終わりなく回るPipeと運用負担
- 公開後、チームは急ごしらえの公開過程で片付けきれなかった問題を把握し始めた
- ユーザーがPipeを作ると、それは明確な終了時点なしに動き続けた
- ログインや更新要求は不要で、RSSリーダーが自動的に更新をポーリングした
- Raffelは、「ゾンビ」のように生成された多数のジョブが、実際にユーザーによるものか不明な利用量を急速に生み出したと見ていた
- Yahooはさらにサーバーを投入し、プログラマーは最も非効率なコードを最適化し、数か月後には安定性が改善した
データ結合ツールとしての力
- Pipesは2000年代半ばのmashup文化とRSS全盛期の上に成長した
- RSSはブログ更新、ポッドキャストのエピソード、検索結果、その他の情報単位を、単純で機械可読な方法で配信する標準として使われていた
- Jon Udellは、RSSがアクセス方法を標準化していたため、Pipesは膨大なソースと個別に対話する問題をある程度避けられたと見ていた
- PipesはRSSだけでなくAtom、RDF、CSVも扱い、少しの作業でWebページを取得して特定データを抽出することもできた
- Yahoo内部サービス、特にFlickrとも接続され、後にはYahoo Query Language、すなわちYQLにも対応した
- YQLは、Yahoo内部製品と外部開発者が共通エンドポイントへクエリできるようにする全社的プロジェクトだった
- Pipesの出力はページへ埋め込むことも、HTML、JSON、KML、RSS、XMLとして生成することもできた
- 外部WebサイトがJavaScriptでPipeワークフローを問い合わせ、結果を受け取る使い方も可能だった
Craigslistによるブロック事例
- Pipesは便利だったが、他サイトに負荷をかけることもあった
- Craigslistは2009年、Yahooではない開発者がCraigslistの賃貸リスト地図を作るためにPipesを使った後、Pipesをブロックした
- CraigslistのCEOは、Pipesが資源を使いすぎると主張した
- ブロックによりインターネット上の複数のmashupがデータを失い、一部の開発者はCraigslistをデータソースとして使わずにPipe自体は維持した
- ブロックは約2週間後に解除された
ビジネスモデルと組織的支援の欠如
- Pipesの衰退は公開時から始まっており、概念から完成した製品へ拡張するには、より大きなチームと明確なミッションが必要だった
- Kent Brewsterは、カンファレンスで人々がPipesを見て印象的だと言っても、サービスにいくら払えるかと聞かれると、Yahooはまだその段階ではないと答えるしかなかったと語った
- 保証された月間Pipe呼び出し回数を購入する商品はなく、その状態では専門家や大企業が投資しにくかった
- Yahooは2008年1月に約1,000人を解雇し、その後Microsoftによる446億ドルの現金・株式での買収提案を断った
- 同年後半には社員の10%、約1,500人を追加で解雇した
- 2008年から2017年の売却と事実上の解体まで、Yahooの財務面で目立った出来事は、2012年にMarissa MayerがAlibaba株の売却に合意したことだった
- Yahooは2005年にAlibaba株を10億ドルで取得し、売却時にはその価値が76億ドルにまで上がっていた
Brickhouseとチームの解体
- Brickhouseは2007年に技術メディアで注目された複数のプロジェクトを生み出した
- BravoNation: 賞賛を送り合うオンラインシステム
- FireEagle: 位置情報を提供しつつプライバシーを仲介するサービス
- KickStart: 大学生向けの求人マッチングサイト
- Yahoo Live: 初期のライブWebカメラ配信サービス
- これらのプロジェクトはいずれも成功にはつながらなかった
- Fakeは2007年4月から産休に入り、2008年6月にYahooを去った
- Bradley Horowitzは2008年2月にGoogleへ移り、Salim Ismailは2008年3月に退社した
- Chad Dickersonも2008年半ばにFakeとほぼ同時期に去った
- Brickhouseは2008年末に閉鎖された
- Pipesチームも散り散りになってYahooを去るか他チームへ移り、サービスの支援は社内の運用担当者へ引き継がれた
Pipesが長く生き残った理由と終了
- SadriはPipes公開の数か月後にPolyvoreを創業した
- Polyvoreはユーザーが画像コラージュを共有できるプラットフォームで、ファッションやインテリアデザインによく使われた
- Polyvoreは2015年にYahooへ買収され、Sadriはその後Sutter Hill Venturesに在籍している
- HoもSadriと近い時期に去り、ChengとRaffelはPipes公開から1年以内に退社した
- Trevorは2010年までYahooに残り、複数チームを移りながらPipesを抱え続けたため、サービスがより長く維持できたと語っている
- TrevorはPipesをPerlからJavaへ書き直し、社内YQL言語と互換性を持たせた
- その後は、いつ停止するかだけが残された状態だったと見ている
- Yahooは2015年にPipesを最終終了した
- Hacker Newsの終了告知スレッドには、今なお代替を探すユーザーや、実現しきれなかった可能性を惜しむ反応が続いた
- Sadriは当時、「コンテナ、たとえばDockerの時代にPipesが公開されていたらよかった」と書き、今日コンテナと呼ばれるものにワンクリックでデプロイする発想があったと述べた
その後のツールと視覚的プログラミングに残した影響
- Pipesはプログラマー、UIデザイナー、プロダクト担当者の世代にインスピレーションを与えた
- Appleが2017年に買収したiPhone/iPad自動化アプリWorkflowは、その後終了・統合され、iOS、iPadOS、macOSのShortcutsとして再提供され、Pipesに近いツールの一つとして言及されている
- Huginnを作ったAndrew Cantinoは、2021年にHacker NewsでYahoo PipesがHuginn制作の着想になったと書いている
- Node-REDは2013年に公開され、Pipesに近い雰囲気を持つツールとして言及されている
- Pipesの代替として挙げられる公開・非公開のツールは増え続けている
- Hacker News終了スレッドのあるユーザーは、Pipesがデータmashupの授業の基盤になり、非開発者の学生でも数時間で小さなカスタムデータアプリを作れたと共有した
- その事例には、位置エンティティ抽出によってストリートアートのブログをジオコーディングし、拡張されたフィードを地図表示へ出力した作業が含まれていた
今日、同様のサービスを作りにくい理由
- Greg Wilsonは、視覚的プログラミングツールは職業・産業別の専門ツールとして広く存在し、Hollywoodの高度なアニメーションでさえYahoo Pipesのようにデータフローブロックをつなぐツールで作られていると語った
- MATLABも数理モデリングのプラットフォームとして世界で約400万人のユーザーを持ち、多くのユーザーが視覚的プログラミングインターフェースを使っていると言及されている
- 汎用のグラフィカルツールが広く普及しなかった理由の一つとして、著作権の不確実性が挙げられる
- Anil Dashは2007年のO’ReillyによるPipes記事へのコメントで、フィードの存在が購読、頻繁なポーリング、再掲載を暗黙に許可しているのかという問いに答えがないと書いた
- 16年後になってもその問いは明確に解決されておらず、訴訟リスクは無料・有料サービスを作ろうとする企業に萎縮効果を与えうる
- 現在のインターネットでは自由に利用できる情報フィードがさらに閉ざされ、一般的なWebページを取得してデータを解析するスクレイピングもより強く制限されている
- Sadriは、多くの正規APIが有料プランの背後にある商用APIになったと述べている
- それでもPipesへの愛着は残っており、Sadriは今日のインフラで「Pipes 2」のような次世代版を作れるかを考えることがあると語った
1件のコメント
Hacker Newsのコメント
Retoolの社員としてこの記事に携わったが、今回は開発者に大きな影響を与えた新しいプログラミング環境を扱う定期シリーズの第2弾だ。
こうした記事は愛情を込めて作る仕事であり、自分たちに形成的な影響を与えた製品を作った元のチームと直接話せるのがうれしい。
Retoolのような製品を作るうえで最も興味深い部分は、過去のアイデアの進化だ。古いコンピューティング論文や製品には、時代を先取りしていたり、業界の変化の中で消えていった優れたアイデアが数多くある。
Pipesは新製品のRetool Workflowsを作る際の参考になったし、今後取り上げたいプログラミング環境のアイデアもたくさんあるが、それぞれ思い入れのある環境があればぜひ教えてほしい。
最初の深掘り記事はVisual Basicだった: https://retool.com/visual-basic
Retool Workflows: https://retool.com/workflows
全体的にかなりカクつき、スクロールジャックがひどい。Chromiumのほうがずっと滑らかだが、それでもスクロールジャックは良くない。
普通ならLinuxを重要な対象プラットフォームとは見なさないだろうが、プログラミング関連のコンテンツなら話は別かもしれない。
他の読者には、最初の画面のデスクトップで何でもクリックしてみることを勧めたい。
仕事で一番好きだったプロジェクト認知の手法がPipesで、あれほど速いやり方はまだ使ったことがない。
Yahoo PipeでJiraプロジェクトを10〜15件、GitHubのコミットストリームを30〜50件まとめて重複排除し、1つのRSSフィードにしてGoogle Readerで読んでいた。
誰が何をいつどこで変えたのかを素早く把握でき、RSSだったのでメールを漁ったり複数の通知ページを見る必要がなく、素晴らしかった。
Yahoo PipesとYQLが本当に恋しい。
2009年にはjQueryの上に、実質的にクロスドメインXHR(AJAX)プラグインを作って、クライアント側で任意のWebページを取得し、CSSセレクタから変換したXPathで問い合わせられるようにしていた。
YQLがJSONPを返してくれて、すべてが魔法のように感じられた時代だった。
しかもUIにjQueryを使っているのも利点だ。
IoT向けとして紹介されているが、非常に柔軟なのでほぼ何にでも使える。
https://nodered.org
当時はjQueryだけでSpotifyのようなクライアントアプリを作り、radioblogclubやVK.comでMP3を検索・ストリーミングし、last.fmからメタデータと類似レコメンドを取得していた。
今まで見た中で最もカクつくアニメーションだ。AndroidのChrome、Pixel 7では完全に使い物にならないが、テキスト版はある？
このページのタブが表示されているだけで、すべてのChromeウィンドウが使えなくなる。
Chromiumのほうがかなり良いが、スクロールジャックは依然として深刻だ。
正しく動けばアニメーションはかなり良さそうだが、読者を追い返すためにこれだけの作業をしたようで残念だ。
名前も似ている最近のワークフロー自動化ツールの中では、気に入っているPipedreamを勧めたい: https://pipedream.com/
Yahoo Pipesスタイルの自動化を探しているなら、ぜひ試す価値がある。
関係者ではなく、満足しているユーザーなだけだ。
どういう意味か見たければ https://gerikson.com/hnlo/ で todsacerdoti を検索すればいい。
積み上げたHNカルマの量を見ると、かなりうまくいっているようだ。
参考までに、創業者です。
今週リリースしたオープンソースのクラウドスクリプティングエンジンFlowpipeも興味を引くかもしれない。
HCLでパイプラインを作成し、HTTPクエリの接続、コンテナの実行、Lambda互換関数の実行、データベースクエリなどを自分のマシンとCLIから行える。
クラウドリソースをSQLでクエリするオープンソースプロジェクトSteampipeとも組み合わせられ、プラグインは139個以上ある。
私たちはよりDevOps寄りに注力しているが、こうしたものを「pipes」と呼ぶようになった背景にはYahoo Pipesからの着想もある。
https://github.com/turbot/flowpipe
https://github.com/turbot/steampipe
select * from cloudがいい要約だし、Flowpipeも確認してみる。大学時代、寮の部屋選びの順番をランダムに決めるときにPipesを使った。
NY TimesのWebサイトのトップ見出しを取得してハッシュ化し、1〜6の数字を決定論的に引き出すようにした。
夏の間に離れた場所で進めながら、自分でコードを実行する必要もなく、全員に公平だと納得してもらえる最善の方法で、実用的でもあり楽しくもあった。
Pipesは間違いなく素晴らしかった。
広く使われていたRSSのような技術のおかげで、緩やかでオープンな相互運用性が残っていたWeb 2.0黄金期にうまくはまっていた。
単純なもの同士をつなぎ、単純だが有用なものを作るのに効果的だった。
ただ、この深掘り記事の途方もないデザインと作業量はいったい何なのかと思う。Retoolは本当に力を入れていて、なぜもっと早くやらなかったのか不思議なくらいだ。
こういう記事がどう作られているのか興味深い。
相当な手間がかかっていて、最終結果まで磨き上げるのにかなり時間がかかったのは明らかだ。高品質なコンテンツと磨き込みには高いコストが伴うからだ。
それでも目的はまだよく分からない。マーケティング記事のようには見えないが、行間のメッセージは明らかにPipesが好きだったならRetoolも好きになるはずという方向に読める。
制作クオリティは高く、URLも単なる
retool.com/pipesなので、ただのブログ記事には見えない。AWS Step FunctionsがYahoo Pipesに似ていると気づくまで少し時間がかかった。
そこまでシンプルでもなく、クリック可能な構成要素もそれほど多くないが、それにこんなに遅く気づいたのが不思議だった。
もっと洞察力のある人なら、どこが違うのか指摘してくれるかもしれない。