Bina sahaja: Cara kami mereka bentuk Streamlit untuk memihak anda ke arah kemajuan ke hadapan

Asalnya diterbitkan di blog Streamlit oleh Thiago Teixeira

Jika anda membaca ini, anda mungkin sudah biasa dengan Streamlit. Jika tidak, berikut adalah ringkasannya: Streamlit ialah rangka kerja Python untuk membina aplikasi data. Ia mempunyai pendapat, ia mempunyai bateri yang disertakan dan ia sangat terikat dengan sistem reka bentuk tertentu.

• Ia tertumpu pada apl data. Semua yang kami lakukan berpunca daripada ini. Kami tidak menyasarkan apl generik seperti yang terdapat pada telefon anda atau SaaS kegemaran anda, tetapi jenis saintis data apl dan jurutera ML perlu menjadikan kerja mereka berkesan di organisasi mereka.
• Ini adalah pendapat kerana kami ingin mempromosikan aliran kerja yang pantas dan berulang dan menegakkan perkara yang kami fikirkan sebagai amalan terbaik dalam kejuruteraan.
• Ia mempunyai bateri yang disertakan jadi kebanyakan perkara yang anda perlukan untuk bermula adalah dalam perpustakaan itu sendiri.
• Dan akhirnya, ia terikat dengan sistem reka bentuk supaya anda tidak meluangkan masa membina perpustakaan komponen, bahasa visual atau identiti. Anda baru sahaja bermula — dan cepat.

Pada ketika ini, saya boleh memberitahu anda tentang cara kami memulakan Streamlit. Mengenai bagaimana ia bermula dari firasat yang baik, berdasarkan pengalaman kami sebelum ini dalam industri dan akademik. Mengenai cara kami menyelami jauh ke dalam syarikat yang berbeza dan memerhati saintis data dan jurutera ML mereka di tempat kerja untuk membentuk Streamlit. Tetapi Adrien sudah melakukannya dengan baik 5 tahun lalu, dan saya rasa saya tidak boleh mengatasinya!

Sebaliknya, saya akan bercakap tentang cara tumpuan mendalam kami pada apl data diterjemahkan kepada keputusan produk yang kami buat setiap hari. Dan untuk ini, saya akan mulakan dengan kisah …

Sewa baharu 10x ganda

Pada suatu masa dahulu, pasukan Sains Data membina model ramalan yang berkuasa bagi metrik syarikat yang paling penting. Pasukan Kewangan melihatnya dan menyukainya, dan kemudian meminta versi langsung yang boleh mereka gunakan dalam mesyuarat mingguan mereka. Jadi Pasukan Data memfailkan permintaan dengan Pasukan Alatan untuk membina apl data dan Pasukan Alatan meletakkannya pada baris gilir mereka.

Tiga bulan dan banyak mesyuarat kemudian, apl itu dihantar dan ia cantik.

Tetapi terdapat kedutan: Apabila Kewangan mencubanya, ia bukanlah apa yang mereka perlukan. Jadi mereka memfailkan permintaan lain dengan Pasukan Data, yang menyerahkannya kepada Pasukan Alatan dan Pasukan Alatan meletakkannya pada baris gilir mereka. Banyak bulan berlalu.

Pada ketika itu, Pekerja Baharu yang tidak curiga telah menyertai Pasukan Data dan telah diberikan projek pemula: Menyusun apl data pantas untuk menyahsekat Pasukan Kewangan sementara mereka menunggu apl sebenar daripada Pasukan Alat .

Selepas beberapa googling, New Hire menemui Streamlit dan, dalam masa sehari, dapat berkongsi apl minimum dengan rakan sekerja. Ia tidak sempurna, tetapi dia menangani beberapa maklum balas dan mengemas kini apl. Keesokan harinya, dia menunjukkannya kepada kenalannya dalam Pasukan Kewangan, mendapat lebih banyak maklum balas dan memperhalusi apl itu dengan sewajarnya.

Dalam masa tiga hari, Pasukan Kewangan kerap menggunakan apl itu dalam mesyuarat mereka. Mereka mendapat lebih banyak maklum balas dan Penyewaan Baharu segera menanganinya dalam versi yang lebih baharu.

Dalam masa seminggu, Ketua Pegawai Eksekutif menggunakan apl tersebut dan Pekerja Baharu telah dipuji sebagai wira ?

Mengapa ini berlaku

Kami telah melihat kisah itu berlaku berkali-kali. Sebab apl New Hire menang akhirnya adalah kerana apl ringkas hari ini adalah lebih baik daripada apl yang terlalu direka bentuk lewat 3 bulan.

Malah, inilah cara syarikat permulaan terbaik membina produk mereka! Mereka menghantar produk berdaya maju minimum (MVP), meletakkannya di tangan pelanggan secepat mungkin dan berulang tanpa henti.

Dan dalam proses itu, mereka secara berperingkat mengeras infrastruktur asas. Kerana terdapat akibat daripada cerita New Hire: Sambil pasukan terus menggunakan apl itu, mereka secara beransur-ansur menghasilkannya.

Set transformasi Panda yang dipesan lebih dahulu yang sangat perlahan? Mereka menariknya ke dalam saluran paip data yang berasingan dan beberapa jadual terwujud.

Pengiraan kompleks yang ingin digunakan oleh apl lain? Mereka memindahkannya ke perkhidmatan RESTful. Mereka memfaktorkan semula apl ke dalam berbilang halaman apabila ia berkembang. Mereka menulis ujian, mereka menyediakan CI. Dan apl itu menjadi kalis peluru.

Faedah aliran ini jelas:

1. Anda membina apl yang lebih baik kerana anda sering tidak tahu perkara yang anda perlukan sehingga anda mencubanya. Oleh itu, dengan membina dan menguji pengguna, dan membina dan menguji pengguna sekali lagi, anda akan mendapat apl yang lebih baik berbanding jika anda telah merancang semuanya lebih awal hanya untuk menyedari bahawa ia bukanlah penyelesaian yang anda fikirkan.
2. Anda mendapat nilai dari hari 1. Semasa anda membina dan menguji pengguna, anda sudah mempunyai apl yang berguna. Dan ia semakin berguna sepanjang perjalanan.
3. Anda tidak terlalu membina. Daripada membina saluran paip pada masa yang sama semasa anda membina apl anda, anda cuma mengeluarkan apl itu dan kemudian mengeraskannya kerana ia membuktikan kegunaannya. Walau bagaimanapun, tidak semua apl berguna dan tidak semua apl berguna dapat bertahan cukup lama sehingga memerlukan pengerasan. Jadi anda hanya menghabiskan kitaran otak berharga anda pada apl yang berguna dan tahan lama.

Cara anda bermula adalah mudah: Anda bina sahaja.

Reka bentuk yang disengajakan

Kami suka beranggapan bahawa bukan kebetulan kisah New Hire berlaku di banyak syarikat yang berbeza. Kami suka fikir cerita ini berlaku kerana kami sengaja mereka bentuk Streamlit untuk mempromosikan kemajuan ke hadapan.

Apabila anda mula menulis apl, kemajuan ke hadapan bermakna mempunyai draf dalam masa 5 minit yang sudah berguna dalam beberapa cara. Dan satu perkara yang pasti menjadikan aplikasi lebih berguna ialah interaktiviti. Jadi, dari awal lagi, kami mempunyai perasaan yang kuat bahawa kami harus menjadikan interaktiviti semudah mungkin.

Sebagai contoh, anda tidak perlu membuat "Paparan" dengan peluncur di dalamnya, kemudian "Pengawal" dengan fungsi panggil balik yang mengubah suai "Model" yang digunakan oleh peluncur (dengan kata lain, paradigma MVC ). Sebaliknya kami menghasilkan penyelesaian satu baris:

nilai = st.slider("Pilih nombor", 0, 100)

Anda menaip itu dan dapatkan apl yang sudah melakukan sesuatu. Kemajuan ke hadapan!

Kemudian, apabila membina Keadaan Sesi dua tahun kemudian, kami dengan cepat mengetahui bahawa API yang dicadangkan akan mudah membawa kepada ralat luar demi satu, dan satu-satunya penyelesaian yang berkesan ialah panggilan balik. Disebabkan oleh pengalaman masa lalu kami dengan MVC dan paradigma yang serupa, kami meluangkan masa yang agak lama untuk menyelesaikan masalah itu untuk menghasilkan versi panggilan balik "Streamlit-y" yang jelas yang mengelakkan semua kerumitan itu. Dan - lebih penting lagi - penyelesaian itu tidak memaksa anda untuk menggunakan panggilan balik dari awal, tetapi membolehkan anda melapiskannya kemudian seperti yang diperlukan. Kemajuan ke hadapan!

Contoh lain yang dekat dan sayang kepada kami —dan pastinya kepada masyarakat — ialah penggayaan. Di satu pihak, perkara paling mudah untuk kami lakukan ialah dengan hanya menggunakan sokongan untuk CSS terus ke Streamlit, dengan sesuatu seperti st.css(...) atau st.write(..., style="css goes here "). Tetapi apabila kami bereksperimen dengannya, kami mendapati akses yang tidak terikat kepada penggayaan dengan cepat menjadi penghalang ke arah kemajuan ke hadapan. Daripada menyampaikan versi pertama itu kepada pihak berkepentingan, orang ramai terjebak menyisir melalui MDN, melawan lata, mengubah pemilih dan obses tentang piksel tunggal. Selain itu, hasil akhirnya selalunya mengelupas dan mengganggu.

Jadi kami menangani permintaan ini dengan bertanya kepada diri sendiri soalan ini:

• “Apakah masalah asas yang cuba diselesaikan oleh orang ramai?”
• “Seberapa biasa masalah itu?”
• “Bolehkah kami menyelesaikannya sendiri dan membantu membebaskan pembangun?”

Bergantung pada jawapan kepada soalan ini, kami mengikuti salah satu daripada dua pendekatan:

1. Sediakan satu baris, penyelesaian pendapat untuk masalah

   Ini berlaku beberapa bulan yang lalu. Kami mendapati ramai pembangun menggunakan penggodaman CSS untuk meletakkan logo di penjuru kiri sebelah atas apl mereka, jadi kami memutuskan untuk memberi mereka penyelesaian satu baris dengan st.logo(). Perintah baharu ini melukis logo tersuai mereka, menjadikannya responsif kepada keadaan bar sisi, memastikan ia tidak bertindih dengan mana-mana kandungan dan hanya kelihatan baik secara lalai.

   Begitu juga cara kami menambahkan warna teks, garisan di bawah pengepala, sempadan di sekeliling bekas, penjajaran menegak, ikon Bahan dan sebagainya. Mereka sememangnya penyelesaian yang mempunyai pendapat dari segi visual dan tingkah laku, tetapi kelebihannya ialah anda hanya mengatakan apa yang anda mahu, Streamlit melakukannya, dan anda meneruskan ke perkara seterusnya. Kemajuan ke hadapan!

2. Sediakan set tombol pilihan susun … dan tonton

   Apabila penyelesaian pendapat satu baris tidak dapat memotongnya, kami memperkenalkan set "tombol" yang minimum, perhatikan hasilnya dan ulangi. Memandangkan kami tidak mahu memecahkan keserasian, kebanyakan ciri kami adalah pintu sehala, bermakna kami mesti meneruskan dengan berhati-hati.

   Contohnya ialah tema. Semua orang mahu apl mereka sepadan dengan warna syarikat mereka dan, sudah tentu, warna yang tepat berbeza mengikut syarikat. Tetapi antara muka Streamlit terdiri daripada beberapa dozen warna, dan memilih kombinasi yang menarik secara visual boleh mengambil masa beberapa jam. Jadi tikaman pertama kami pada masalah ini ialah membenarkan anda memilih hanya 4 warna, dan Streamlit mengira semua warna lain untuk anda. Kemajuan ke hadapan!

   Kami kini sibuk di belakang tabir memikirkan tikaman kedua mengenai masalah ini — penyelesaian yang diperluas yang memberikan anda lebih banyak tombol (di luar warna, malah!) tanpa mengorbankan kelajuan lelaran. Begitu juga, kami juga mempertimbangkan pilihan susun atur baharu yang lebih fleksibel melangkaui lajur.

   Kami tidak mempunyai apa-apa untuk diumumkan sekarang, tetapi pasti berjaga-jaga ?

Ringkasnya, kami tidak mahu apa-apa yang mengganggu anda daripada kemajuan ke hadapan. Dengan setiap langkah yang kami ambil, kami berusaha sedaya upaya untuk menyediakan rangka kerja yang mengabstraksi HTML, JS, CSS, HTTP, laluan, siri, panggilan balik dan semua jenis butiran kejuruteraan. Dengan cara ini, anda dapat menumpukan pada meletakkan kuasa data di hujung jari pemegang kepentingan anda supaya mereka juga boleh membuat kemajuan ke hadapan.

Lelaran menjadikan sempurna

Di Streamlit, kami adalah pengguna tegar Streamlit sendiri, yang bermaksud kami mempunyai kegusaran dan permintaan ciri kami sendiri. Kami berkongsi titik kesakitan anda, dan kami sentiasa mengulangi pustaka. Kami tidak pernah mahu berhenti mengulang! Komitmen kami terhadap perkara ini ditunjukkan dalam cara kami menghantar keluaran baharu setiap bulan.

Kami juga diilhamkan oleh komuniti Streamlit dan kepintaran anda. Kami sentiasa menemui apl dan komponen tersuai yang menolak sempadan Streamlit dengan cara yang tidak pernah kami fikirkan, memberikan kami idea baharu untuk perkara yang dibawa ke dalam perpustakaan teras. Komuniti merupakan bahagian yang terbaik dalam kerja ini!

Disebabkan itu, kami mempunyai lebih banyak lagi untuk anda. Kami membangunkan secara terbuka, supaya anda sentiasa boleh mencari peta jalan kami di roadmap.streamlit.app atau menghadiri Pameran Suku Tahunan seterusnya, di mana pengurus produk kami membincangkan perkara terkini dalam Streamlit, seperti penjajaran menegak dan tema lanjutan.

Keindahan tentang lelaran ialah hari-hari terbaik sentiasa di hadapan. Kami berbesar hati untuk membawa anda bersama-sama dalam perjalanan.

Selamat Menipis! ?

Atas ialah kandungan terperinci Bina sahaja: Cara kami mereka bentuk Streamlit untuk memihak anda ke arah kemajuan ke hadapan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!