ただ構築するだけ: 前進する方向にバイアスをかけるための Streamlit の設計方法

元々は、Thiago Teixeira による Streamlit ブログで公開されました

これを読んでいるあなたは、おそらく Streamlit についてすでによく知っているでしょう。そうでない場合は、以下に概要を示します。Streamlit は、データ アプリを構築するための Python フレームワークです。独自の意見があり、バッテリーが組み込まれており、特定の設計システムと深く結びついています。

• データ アプリに重点を置いています。 私たちの活動はすべてこれに基づいています。携帯電話やお気に入りの SaaS のような一般的なアプリは対象としていませんが、データ サイエンティストや ML エンジニアが組織での仕事に影響を与えるために必要な種類のアプリは対象ではありません。
• これは独自の意見です。なぜなら、私たちは高速で反復的なワークフローを推進し、エンジニアリングにおけるベスト プラクティスと考えられるものを守りたいからです。
• 電池が付属しているので、使用を開始するために必要なもののほとんどはライブラリ自体にあります。
• そして最後に、デザイン システムに関連付けられているので、コンポーネント ライブラリ、ビジュアル言語、または ID の構築に時間を費やす必要はありません。始めるだけです。すぐに。

この時点で、Streamlit を始めた経緯についてお話しできました。産業界と学術界でのこれまでの経験に基づいた、良い予感からそれがどのように始まったかについて。 Streamlit を形作るために、さまざまな企業を深く調査し、データ サイエンティストと ML エンジニアがどのように働いているかを観察した方法について。しかし、エイドリアンは 5 年前にすでにそれを非常にうまくやっており、私がそれを超えることはできないと思います!

それでは代わりに、データ アプリに重点を置いていることが、私たちが毎日行っている製品の意思決定にどのように反映されているかについてお話します。このために、物語から始めましょう…

10 倍の新規採用

かつて、データ サイエンス チームは、会社の最も重要な指標の強力な予測モデルを構築しました。財務チームはそれを見て気に入ったので、毎週の会議で使用できるライブ バージョンを求めました。そこで、データ チームはデータ アプリを構築するようツール チームにリクエストを提出し、ツール チームはそれをキューに入れました。

3 か月後、何度もミーティングを重ねた後、アプリが配信されましたが、それはとても素晴らしかったです。

しかし、問題点がありました。財務部門がそれを試したとき、それは彼らが必要としていたものではありませんでした。そこで彼らはデータ チームに別のリクエストを提出し、データ チームはそれをツール チームに渡し、ツール チームはそれをキューに入れました。何ヶ月も経ちました。

その時点で、何の疑いも持たない新入社員がデータ チームに加わり、スターター プロジェクトを割り当てられました。それは、ツール チームからの本物のアプリを待っている間に、財務チームのブロックを解除するための簡単なデータ アプリをまとめるというものでした。 .

新入社員はグーグルで検索した結果、Streamlit を発見し、1 日以内に最小限のアプリを同僚と共有することができました。完璧ではありませんでしたが、彼女はフィードバックの一部に対処し、アプリを更新しました。翌日、彼女はそれを財務チームの担当者に見せ、さらなるフィードバックを得て、それに応じてアプリを改良しました。

3 日以内に、財務チームは会議で定期的にアプリを使用するようになりました。さらに多くのフィードバックがあり、新入社員はすぐに新しいバージョンでそれに対応しました。

1 週間以内に CEO がアプリを使用し、新入社員は英雄として称賛されました ?

なぜこれが起こるのか

私たちはそのような話が何度も起こるのを見てきました。最終的に新入社員のアプリが勝つ理由は、3 か月遅れて過剰にデザインされたアプリよりも、今日のシンプルなアプリの方が優れているからです。

実際、これはまさに最高のスタートアップが製品を構築する方法です。彼らは実用最小限の製品 (MVP) を出荷し、できるだけ早く顧客の手に渡し、絶え間なく繰り返します。

そしてその過程で、基盤となるインフラストラクチャを段階的に強化します。なぜなら、この新入社員の話には当然の帰結があるからです。チームがアプリを使い続けると、徐々にアプリを製品化していきます。

非常に遅い特注の Pandas 変換のセットですか?彼らはそれを別のデータ パイプラインといくつかの実体化されたテーブルに取り込みます。

他のアプリが使用したい複雑な計算?彼らはそれを RESTful サービスに移行します。アプリが成長するにつれて、アプリを複数のページにリファクタリングします。彼らはテストを書き、CI をセットアップします。そしてアプリは完全に安全になります。

このフローの利点は明らかです:

1. より良いアプリを構築できます。それは、試してみるまで何が必要なのかわからないことが多いからです。したがって、構築してユーザー テストを行い、再度構築してユーザー テストを行うことで、事前にすべての計画を立てて、後になってそれが自分が思っていたソリューションではないことに気づくよりも、より良いアプリが完成することになります。
2. 初日から価値を得ることができます。 構築してユーザー テストを行っているとき、すでに便利なアプリができています。そして、それは途中でますます便利になります。
3. オーバービルドはしません。 アプリの構築と同時にパイプラインを構築するのではなく、アプリを取り出して、その有用性を証明しながら強化するだけです。ただし、すべてのアプリが有用であるわけではなく、すべての有用なアプリが強化を必要とするほど長く存続するわけでもありません。したがって、貴重な脳のサイクルを、有用で長寿命のアプリにのみ費やすことになります。

開始方法は簡単です。ただ構築するだけです。

意図的なデザイン

私たちは、この新入社員の話が非常に多くの異なる企業で起こったのは偶然ではないと考えたいと思っています。私たちは、前進を促進するために Streamlit を意図的に設計しているため、この話が起こったと考えたいと思います。

初めてアプリを書き始めるとき、前進とは、何らかの方法ですでに役立つ下書きを 5 分以内に作成することを意味します。そして、アプリを間違いなくより便利にするものの 1 つは、インタラクティブ性です。そのため、私たちは早い段階から、インタラクティブ性をできるだけシンプルにする必要があるという強い意識を持っていました。

たとえば、スライダーを含む「ビュー」を作成してから、スライダーで使用される「モデル」を変更するコールバック関数を含む「コントローラー」を作成する必要はありません (つまり、MVC パラダイム) ）。代わりに、次の 1 行の解決策を考え出しました。

value = st.slider("数値を選択", 0, 100)

それを入力すると、すでに何かを実行するアプリが表示されます。 前進!

その後、2 年後にセッション状態を構築したとき、提案された API は簡単に off-by-one エラーを引き起こし、機能する唯一の解決策はコールバックであることがすぐにわかりました。 MVC や同様のパラダイムに関する過去の経験に傷ついた私たちは、この問題にかなりの時間を費やして、その複雑さをすべて回避した明らかに「Streamlit-y」 バージョンのコールバックを考案しました。そして、さらに重要なことは、このソリューションでは最初からコールバックの使用を強制するのではなく、必要に応じて後からコールバックを追加できるようにすることです。 前進!

私たちにとって、そして間違いなくコミュニティにとっても身近で大切なもう 1 つの例は、スタイリングです。一方で、私たちにとって最も簡単なことは、st.css(...) や st.write(..., style="css go here) のようなものを使用して、CSS のサポートを Streamlit に直接組み込むことです。 ")。しかし、実際に試してみると、スタイリングへの自由なアクセスは、 すぐに進歩への障害になってしまうことに気付きます。最初のバージョンを関係者に公開するのではなく、人々は MDN を調べたり、カスケードと格闘したり、セレクターを微調整したり、単一のピクセルに執着したりして立ち往生します。さらに、最終結果は不安定で気が散るものになることがよくあります。

そこで、私たちは次のような質問を自分自身に問いかけて、これらのリクエストに取り組みます。

• 「人々が解決しようとしている根本的な問題は何ですか?」
• 「その問題はどのくらい一般的ですか?」
• 「自分たちで解決して、開発者を解放できるでしょうか?」

これらの質問に対する答えに応じて、次の 2 つのアプローチのいずれかに従います。

1. 問題に対する独自の解決策を 1 行で提供します

   これは数か月前の出来事です。多くの開発者が CSS ハックを使用してアプリの左上隅にロゴを配置していることに気づき、st.logo() を使用した 1 行のソリューションを提供することにしました。この新しいコマンドは、カスタム ロゴを描画し、サイドバーの状態に応答できるようにし、コンテンツと重ならないようにし、デフォルトで見栄えが良くなるようにします。

   これは、テキストの色、ヘッダーの下の線、コンテナーの周囲の境界線、垂直方向の配置、マテリアル アイコンなどを追加する方法でもあります。確かにビジュアルや動作の点で独自のソリューションではありますが、利点は、言いたいことを言うだけで、Streamlit がそれを実行し、次の作業に進むことができることです。 前進!

2. 厳選されたノブのセットを提供してください…そして見てください

   たった 1 行の独断的なソリューションでは解決できない場合は、最小限の「ノブ」セットを導入し、結果を観察し、反復します。互換性を壊したくないため、機能のほとんどは一方通行であり、注意して進める必要があります。

   この例は、テーマです。誰もが自分のアプリが会社のカラーに一致することを望んでいますが、もちろん、正確な色は会社によって異なります。しかし、Streamlit のインターフェースは数十の色で構成されており、視覚的に好ましい組み合わせを選択するには数時間かかる場合があります。そこで、この問題に対する私たちの最初の取り組みは、4 色だけを選択させ、他の色はすべて Streamlit が計算することでした。 前進!

   私たちは現在、舞台裏で この問題に対する第 2 の取り組み を検討中です。これは、反復速度を犠牲にすることなく、より多くのノブ (色以外も!) を提供する拡張ソリューションです。同様に、列を超えた、より柔軟な新しいレイアウト オプションも検討しています。

   現時点で発表できることは何もありませんが、ぜひ注目してください?

要するに、私たちは皆さんの前進を邪魔するものは何も望んでいません。私たちはあらゆるステップで、HTML、JS、CSS、HTTP、ルート、シリアル化、コールバック、およびあらゆる種類のエンジニアリングの詳細を抽象化するフレームワークを提供するために全力を尽くしています。こうすることで、関係者がすぐにデータの力を活用できるようにすることに集中でき、関係者も前進できるようになります。

反復を繰り返すことで完璧になる

Streamlit では、私たち自身も Streamlit の熱心なユーザーです。つまり、私たち自身の不満や機能の要望があります。私たちはお客様の問題点を共有し、常にライブラリについて繰り返し検討しています。私たちは反復を決してやめたくありません。これに対する私たちの取り組みは、毎月新しいリリースを出荷する方法に表れています。

私たちは、Streamlit コミュニティと皆さんの創意工夫にもインスピレーションを受けています。私たちは、これまで不可能とは考えられなかった方法で Streamlit の限界を押し上げるアプリやカスタム コンポーネントに常に遭遇し、コア ライブラリに組み込むための新しいアイデアを与えてくれます。この仕事の一番の魅力はコミュニティです!

そのため、私たちはあなたのためにさらに多くのものを用意しています。私たちはオープンな環境で開発を行っているため、ロードマップはいつでもroadmap.streamlit.appで見つけることができます。また、次の四半期ごとのショーケースに参加することもできます。そこでは、当社の製品マネージャーが垂直方向の配置や高度なテーマなどのStreamlitの最新情報について話し合います。

反復の利点は、最良の日が常に到来することです。ご一緒させていただき大変光栄です。

ストリームリットを楽しんでください! ?

以上がただ構築するだけ: 前進する方向にバイアスをかけるための Streamlit の設計方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。