Heim > Backend-Entwicklung > Python-Tutorial > Bauen Sie es einfach auf: Wie wir Streamlit so gestalten, dass es Sie auf den Fortschritt ausgerichtet macht

Bauen Sie es einfach auf: Wie wir Streamlit so gestalten, dass es Sie auf den Fortschritt ausgerichtet macht

WBOY
Freigeben: 2024-08-13 12:24:36
Original
546 Leute haben es durchsucht

Ursprünglich veröffentlicht auf dem Streamlit-Blog von Thiago Teixeira

Wenn Sie dies lesen, kennen Sie Streamlit wahrscheinlich bereits. Falls nicht, hier eine Zusammenfassung: Streamlit ist ein Python-Framework zum Erstellen von Daten-Apps. Es ist eigensinnig, enthält Batterien und ist eng an ein bestimmtes Designsystem gebunden.

  • Der Schwerpunkt liegt auf Daten-Apps.Alles, was wir tun, basiert darauf. Wir zielen nicht auf generische Apps wie die auf Ihrem Telefon oder Ihr bevorzugtes SaaS ab, sondern auf die Arten von Apps, die Datenwissenschaftler und ML-Ingenieure benötigen, um ihre Arbeit in ihren Organisationen wirkungsvoll zu gestalten.
  • Es ist eigensinnig, weil wir einen schnellen, iterativen Arbeitsablauf fördern und die unserer Meinung nach besten Praktiken im Ingenieurwesen aufrechterhalten wollen.
  • Batterien sind im Lieferumfang enthalten sodass sich das meiste, was Sie zum Starten benötigen, in der Bibliothek selbst befindet.
  • Und schließlich ist es an ein Designsystem gebunden, sodass Sie keine Zeit damit verschwenden, eine Komponentenbibliothek, visuelle Sprache oder Identität aufzubauen. Man fängt einfach an – und zwar schnell.

An dieser Stelle könnte ich Ihnen erzählen, wie wir Streamlit gegründet haben. Darüber, wie alles aus einer guten Ahnung heraus begann, basierend auf unseren bisherigen Erfahrungen in Industrie und Wissenschaft. Darüber, wie wir tief in verschiedene Unternehmen eingetaucht sind und ihre Datenwissenschaftler und ML-Ingenieure bei der Arbeit beobachtet haben, um Streamlit zu formen. Aber Adrien hat das schon vor 5 Jahren sehr gut gemacht, und ich glaube nicht, dass ich es toppen kann!

Stattdessen werde ich darüber sprechen, wie sich unser starker Fokus auf Daten-Apps in Produktentscheidungen niederschlägt, die wir jeden Tag treffen. Und dazu beginne ich mit einer Geschichte …

Der 10-fache Neuzugang

Es war einmal ein Data-Science-Team, das ein leistungsstarkes Prognosemodell für die wichtigsten Kennzahlen des Unternehmens erstellte. Das Finanzteam sah es und war begeistert und fragte dann nach einer Live-Version, die es in seinen wöchentlichen Besprechungen verwenden konnte. Also reichte das Datenteam beim Tools-Team eine Anfrage zur Erstellung einer Daten-App ein, und das Tools-Team stellte sie in seine Warteschlange.

Drei Monate und viele Meetings später wurde die App geliefert und sie war wunderschön.

Aber es gab einen Haken: Als die Finanzabteilung es ausprobierte, war es nicht ganz das, was sie brauchten. Also reichten sie eine weitere Anfrage beim Datenteam ein, das sie an das Tools-Team weiterleitete, und das Tools-Team stellte sie in ihre Warteschlange. Viele Monate vergingen.

Zu diesem Zeitpunkt trat ein ahnungsloser neuer Mitarbeiter dem Datenteam bei und erhielt ein Startprojekt: Die Zusammenstellung einer schnellen Daten-App, um das Finanzteam freizugeben, während es auf die echte App vom Tools-Team wartete .

Nach einigem Googeln entdeckte der neue Mitarbeiter Streamlit und konnte innerhalb eines Tages eine Minimal-App mit Kollegen teilen. Es war nicht perfekt, aber sie hat einige Rückmeldungen berücksichtigt und die App aktualisiert. Am nächsten Tag zeigte sie es ihrem Ansprechpartner im Finanzteam, holte sich mehr Feedback und verfeinerte die App entsprechend.

Innerhalb von drei Tagen nutzte das Finanzteam die App regelmäßig in seinen Besprechungen. Sie hatten mehr Feedback und der neue Mitarbeiter ging in neueren Versionen schnell darauf ein.

Innerhalb einer Woche nutzte der CEO die App und der neue Mitarbeiter wurde als Held gefeiert?

Warum das passiert

Wir haben diese Geschichte schon unzählige Male erlebt. Der Grund dafür, dass die App des neuen Mitarbeiters am Ende gewinnt, ist, dass eine einfache App heute besser ist als eine überdesignte App drei Monate zu spät.

Tatsächlich bauen die besten Startups ihre Produkte genau so! Sie liefern ein Minimum Viable Product (MVP), legen es so schnell wie möglich in die Hände der Kunden und iterieren unermüdlich.

Und dabei härten sie die zugrunde liegende Infrastruktur schrittweise ab. Denn die Geschichte des neuen Mitarbeiters hat eine Konsequenz: Während das Team die App weiterhin nutzt, wird sie nach und nach produziert.

Diese Reihe maßgeschneiderter Pandas-Transformationen, die superlangsam sind? Sie ziehen es in eine separate Datenpipeline und einige materialisierte Tabellen.

Diese komplexe Berechnung, die andere Apps verwenden möchten? Sie verschieben es in einen RESTful-Dienst. Sie überarbeiten die App in mehrere Seiten, wenn sie wächst. Sie schreiben Tests, sie richten CI ein. Und die App wird kugelsicher.

Die Vorteile dieses Flusses liegen auf der Hand:

  1. Sie erstellen bessere Apps, weil Sie oft erst wissen, was Sie brauchen, wenn Sie es ausprobieren. Durch Erstellen und Benutzertests und erneutes Erstellen und Benutzertests erhalten Sie am Ende eine bessere App, als wenn Sie das Ganze im Voraus geplant hätten, nur um später zu erkennen, dass es nicht die Lösung ist, die Sie erwartet hatten.
  2. Sie profitieren vom ersten Tag an. Während Sie erstellen und Benutzer testen, haben Sie bereits eine nützliche App. Und mit der Zeit wird es immer nützlicher.
  3. Sie bauen nicht zu viel. Anstatt gleichzeitig mit der Erstellung Ihrer App eine Pipeline zu erstellen, bringen Sie die App einfach heraus und härten sie dann aus, wenn sie ihre Nützlichkeit unter Beweis stellt. Allerdings sind nicht alle Apps nützlich und nicht alle nützlichen Apps leben lange genug, um eine Härtung zu erfordern. Sie verbringen Ihre kostbaren Gehirnzyklen also nur mit Apps, die sowohl nützlich als auch langlebig sind.

Die Art und Weise, wie Sie beginnen, ist einfach: Sie bauen es einfach.

Absichtliches Design

Wir glauben gerne, dass es kein Zufall ist, dass sich die Geschichte des neuen Mitarbeiters in so vielen verschiedenen Unternehmen abspielt. Wir glauben gerne, dass diese Geschichte passiert, weil wir Streamlit absichtlich so gestalten, dass es den Fortschritt vorantreibt.

Wenn Sie zum ersten Mal mit dem Schreiben einer App beginnen, bedeutet Vorwärtsfortschritt, dass Sie in 5 Minuten einen Entwurf haben, der bereits irgendwie nützlich ist. Und eine Sache, die eine App definitiv nützlicher macht, ist die Interaktivität. Deshalb hatten wir schon früh das starke Gefühl, dass wir die Interaktivität so einfach wie möglich gestalten sollten.

Zum Beispiel sollten Sie keine „Ansicht“ mit einem Schieberegler darin erstellen müssen, dann einen „Controller“ mit einer Rückruffunktion, die das vom Schieberegler verwendete „Modell“ (mit anderen Worten das MVC-Paradigma) ändert ). Stattdessen haben wir eine einzeilige Lösung gefunden:

value = st.slider("Wählen Sie eine Zahl", 0, 100)

Sie geben das ein und erhalten eine App, die bereits etwas tut. Vorwärtsfortschritt!

Dann, als wir Session State zwei Jahre später erstellten, stellten wir schnell fest, dass die vorgeschlagene API leicht zu Fehlern führen würde, die nacheinander ablaufen, und dass die einzige Lösung, die funktionierte, Rückrufe waren. Aufgrund unserer früheren Erfahrungen mit MVC und ähnlichen Paradigmen haben wir einige Zeit mit dem Problem verbracht, um eine entschieden „Streamlit-y“-Version von Rückrufen zu entwickeln, die diese Komplexität vermeidet. Und – was noch wichtiger ist – die Lösung zwingt Sie nicht von Anfang an dazu, Rückrufe zu verwenden, sondern ermöglicht es Ihnen, sie später nach Bedarf zu ergänzen. Vorwärtsfortschritt! Ein weiteres Beispiel, das uns – und sicherlich auch der Community – am Herzen liegt, ist das Styling. Einerseits wäre es für uns am einfachsten, die Unterstützung für CSS einfach direkt in Streamlit einzubinden, mit etwas wie st.css(...) oder st.write(..., style="css kommt hierher "). Aber wenn wir damit experimentieren, stellen wir fest, dass der uneingeschränkte Zugang zum Styling schnell zu einem

Hindernis

für den weiteren Fortschritt wird. Anstatt die erste Version den Stakeholdern zur Verfügung zu stellen, bleiben die Leute damit stecken, MDN zu durchkämmen, gegen die Kaskade zu kämpfen, Selektoren zu optimieren und sich mit einzelnen Pixeln zu beschäftigen. Und zu allem Überfluss ist das Endergebnis oft flockig und ablenkend. Also gehen wir diese Anfragen an, indem wir uns die folgenden Fragen stellen:

„Was ist das zugrunde liegende Problem, das die Leute zu lösen versuchen?“
  • „Wie häufig kommt dieses Problem vor?“
  • „Können wir das Problem selbst lösen und dabei helfen, den Entwickler zu befreien?“
  • Abhängig von den Antworten auf diese Fragen verfolgen wir einen von zwei Ansätzen:

  1. Bieten Sie eine einzeilige, eigenwillige Lösung des Problems

    Das ist vor ein paar Monaten passiert. Uns ist aufgefallen, dass unzählige Entwickler CSS-Hacks verwenden, um ein Logo in der oberen linken Ecke ihrer Apps zu platzieren. Deshalb haben wir uns entschieden, ihnen mit st.logo() eine einzeilige Lösung anzubieten. Dieser neue Befehl zeichnet ihr benutzerdefiniertes Logo, reagiert auf den Status der Seitenleiste, stellt sicher, dass es keine Inhalte überlappt und standardmäßig einfach gut aussieht.

    Auf diese Weise haben wir auch Textfarben, Linien unter Überschriften, Rahmen um Container, vertikale Ausrichtung, Materialsymbole usw. hinzugefügt. In Bezug auf Optik und Verhalten handelt es sich dabei sicherlich um eigenwillige Lösungen, aber der Vorteil besteht darin, dass Sie einfach sagen, was Sie wollen, Streamlit macht es und Sie können mit der nächsten Sache fortfahren.

    Vorwärtsfortschritt!

  2. Stellen Sie ein ausgewähltes Set an Knöpfen bereit … und schauen Sie zu

    Wenn eine Lösung mit einer einzeiligen Meinung nicht ausreicht, führen wir einen minimalen Satz von „Knöpfen“ ein, beobachten das Ergebnis und iterieren. Da wir die Kompatibilität nicht beeinträchtigen möchten, handelt es sich bei den meisten unserer Funktionen um Einbahnstraßen, was bedeutet, dass wir mit Vorsicht vorgehen müssen.

    Ein Beispiel hierfür ist Theming. Jeder möchte, dass seine Apps zu den Farben seines Unternehmens passen, und natürlich variieren die genauen Farben je nach Unternehmen. Die Benutzeroberfläche von Streamlit besteht jedoch aus mehreren Dutzend Farben, und die Auswahl einer optisch ansprechenden Kombination kann mehrere Stunden in Anspruch nehmen. Unser erster Versuch, dieses Problem zu lösen, bestand darin, Ihnen die Auswahl von nur vier Farben zu ermöglichen, und Streamlit berechnet alle anderen für Sie. Vorwärtsfortschritt!

    Wir sind jetzt hinter den Kulissen damit beschäftigt, uns einen zweiten Versuch für dieses Problem auszudenken – eine erweiterte Lösung, die Ihnen mehr Knöpfe (sogar über die Farben hinaus!) bietet, ohne die Iterationsgeschwindigkeit zu beeinträchtigen. Ebenso erwägen wir neue, flexiblere Layoutoptionen über die Spalten hinaus.

    Wir haben im Moment nichts zu verkünden, aber halten Sie auf jeden Fall die Augen offen ?

Zusammenfassend lässt sich sagen, dass wir nicht möchten, dass Sie durch irgendetwas vom weiteren Fortschritt abgelenkt werden. Bei jedem Schritt, den wir unternehmen, geben wir unser Bestes, um ein Framework bereitzustellen, das HTML, JS, CSS, HTTP, Routen, Serialisierung, Rückrufe und alle möglichen technischen Details abstrahiert. Auf diese Weise können Sie sich darauf konzentrieren, die Macht der Daten Ihren Stakeholdern zur Verfügung zu stellen, damit auch diese Fortschritte machen können.

Just build it: How we design Streamlit to bias you toward forward progress

Iteration macht den Meister

Bei Streamlit sind wir selbst begeisterte Nutzer von Streamlit, was bedeutet, dass wir unsere eigenen Lieblinge und Funktionswünsche haben. Wir teilen Ihre Schwachstellen und arbeiten ständig an der Bibliothek. Wir wollen nie aufhören zu iterieren! Unser Engagement dafür zeigt sich in der Art und Weise, wie wir jeden Monat eine neue Version veröffentlichen.

Wir lassen uns auch von der Streamlit-Community und Ihrem Einfallsreichtum inspirieren. Wir stoßen ständig auf Apps und benutzerdefinierte Komponenten, die die Grenzen von Streamlit auf eine Weise erweitern, die wir nie für möglich gehalten hätten, und uns neue Ideen für Dinge geben, die wir in die Kernbibliothek integrieren können. Die Community ist mit Sicherheit das Beste an diesem Job!

Aus diesem Grund haben wir noch viel mehr für Sie auf Lager. Wir entwickeln offen, sodass Sie unsere Roadmap immer unter roadmap.streamlit.app finden oder am nächsten Quarterly Showcase teilnehmen können, bei dem unsere Produktmanager die neuesten Entwicklungen in Streamlit besprechen, wie z. B. vertikale Ausrichtung und erweitertes Theming.

Das Schöne am Iterieren ist, dass die besten Tage immer vor uns liegen. Wir fühlen uns geehrt, Sie dabei zu haben.

Viel Spaß beim Streamliten! ?

Das obige ist der detaillierte Inhalt vonBauen Sie es einfach auf: Wie wir Streamlit so gestalten, dass es Sie auf den Fortschritt ausgerichtet macht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Quelle:dev.to
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage