فقط آن را بسازید: چگونه Streamlit را طراحی می کنیم تا شما را به سمت پیشرفت رو به جلو سوق دهد
ابتدا توسط تیاگو تکسیرا در وبلاگ Streamlit منتشر شد
اگر در حال خواندن این مطلب هستید، احتمالاً از قبل با Streamlit آشنا هستید. اگر نه، در اینجا خلاصه ای وجود دارد: Streamlit یک چارچوب پایتون برای ساخت برنامه های داده است. این مورد نظر است، دارای باتری است، و عمیقاً به یک سیستم طراحی خاص گره خورده است.
- این برنامه بر روی برنامه های داده متمرکز شده است. هر کاری که ما انجام می دهیم از این نشات می گیرد. ما برنامههای عمومی مانند برنامههای موجود در تلفن شما یا SaaS مورد علاقهتان را هدف قرار نمیدهیم، اما دانشمندان دادههای برنامهها و مهندسان ML باید کار خود را در سازمانهایشان تأثیرگذار کنند.
- نظری است زیرا ما میخواهیم یک گردش کار سریع و تکرار شونده را ترویج کنیم و آنچه را که فکر میکنیم بهترین روش در مهندسی میدانیم، حفظ کنیم.
- دارای باتری های گنجانده شده است بنابراین بیشتر چیزی که برای شروع نیاز دارید در خود کتابخانه است.
- و در نهایت، این به یک سیستم طراحی گره خورده است بنابراین وقت خود را صرف ساختن یک کتابخانه جزء، زبان بصری یا هویت نمی کنید. شما تازه شروع کرده اید – و سریع.
در این مرحله، میتوانم درباره نحوه شروع Streamlit به شما بگویم. در مورد اینکه چگونه بر اساس تجربه قبلی ما در صنعت و دانشگاه، از یک تصور خوب شروع شد. در مورد اینکه چگونه به شرکت های مختلف وارد شدیم و دانشمندان داده و مهندسان ML آنها را در حال کار برای شکل دادن به Streamlit مشاهده کردیم. اما آدرین قبلاً 5 سال پیش این کار را خیلی خوب انجام داده بود و فکر نمی کنم بتوانم آن را بالاتر ببرم!
بنابراین در عوض، من در مورد اینکه چگونه تمرکز عمیق ما بر برنامه های داده به تصمیمات محصولی که هر روز می گیریم تبدیل می شود صحبت خواهم کرد. و برای این، من با یک داستان شروع می کنم…
10 برابر استخدام جدید
روزی روزگاری، یک تیم علم داده یک مدل پیشبینی قدرتمند از مهمترین معیارهای شرکت ساختند. تیم مالی آن را دید و آن را دوست داشت، و سپس درخواست نسخه زنده ای کردند که بتوانند در جلسات هفتگی خود از آن استفاده کنند. بنابراین تیم داده درخواستی را با تیم ابزار برای ساخت یک برنامه داده ارسال کرد و تیم ابزار آن را در صف خود قرار داد.
سه ماه و جلسات زیادی بعد، برنامه تحویل داده شد و زیبا بود.
اما یک چین و چروک وجود داشت: وقتی فایننس آن را امتحان کرد، آن چیزی که آنها نیاز داشتند نبود. بنابراین آنها درخواست دیگری را با تیم داده ارسال کردند که آن را به تیم ابزار ارسال کرد و تیم ابزار آن را در صف خود قرار داد. ماه های زیادی گذشت.
در آن مرحله، یک New Hire ناشناس به تیم داده ملحق شد و یک پروژه آغازین به او محول شد: ایجاد یک برنامه داده سریع برای رفع انسداد تیم مالی در حالی که آنها منتظر بودند. برنامه واقعی از تیم ابزار.
پس از مدتی جستجو، New Hire Streamlit را کشف کرد و در عرض یک روز توانست یک اپلیکیشن حداقلی را با همکاران خود به اشتراک بگذارد. کامل نبود، اما او به برخی از بازخوردها پرداخت و برنامه را به روز کرد. روز بعد، او آن را به مخاطب خود در تیم مالی نشان داد، بازخورد بیشتری دریافت کرد و بر این اساس برنامه را اصلاح کرد.
در عرض سه روز، تیم مالی به طور منظم از برنامه در جلسات خود استفاده می کرد. آنها بازخورد بیشتری داشتند و New Hire به سرعت در نسخه های جدیدتر به آن پرداخت.
در عرض یک هفته، مدیر عامل از برنامه استفاده کرد و استخدام جدید به عنوان یک قهرمان مورد ستایش قرار گرفت.
چرا این اتفاق می افتد
ما بارها شاهد وقوع آن داستان بوده ایم. دلیل برنده شدن برنامه New Hire در پایان این است که یک برنامه ساده امروز بهتر از یک برنامه بیش از حد طراحی شده با 3 ماه تاخیر است.
در واقع بهترین استارت آپ ها دقیقاً اینگونه محصولات خود را می سازند! آنها حداقل محصول قابل دوام (MVP) را ارسال می کنند، آن را در اسرع وقت در اختیار مشتریان قرار می دهند و بی وقفه تکرار می کنند.
و در این فرآیند، آنها به تدریج زیرساخت های زیرین را سخت می کنند. از آنجایی که داستان New Hire نتیجهای دارد: با ادامه استفاده تیم از برنامه، آنها به تدریج آن را تولید میکنند.
مجموعه ای از تغییرات سفارشی پانداها که بسیار کند هستند؟ آنها آن را به یک خط لوله داده جداگانه و برخی جداول تحقق یافته می کشانند.
آن محاسبات پیچیده ای که سایر برنامه ها می خواهند از آن استفاده کنند؟ آنها آن را به یک سرویس RESTful منتقل می کنند. آنها با رشد برنامه، آن را به چندین صفحه تبدیل می کنند. تست می نویسند، CI راه اندازی می کنند. و برنامه ضد گلوله می شود.
مزایای این جریان واضح است:
- شما برنامه های بهتری می سازید زیرا اغلب تا زمانی که آن را امتحان نکنید نمی دانید به چه چیزی نیاز دارید. بنابراین، با ساختن و آزمایش کاربر، و ساختن و آزمایش مجدد کاربر، در نهایت به یک برنامه بهتر از برنامهریزی کامل برنامهریزی شدهاید و با تأخیر متوجه میشوید که این راهحلی نیست که فکر میکردید.
- شما از روز 1 ارزش دریافت می کنید. همانطور که در حال ساخت و آزمایش کاربر هستید، شما در حال حاضر یک برنامه مفید داشته باشید و فقط در طول مسیر مفیدتر و بیشتر می شود.
- شما بیش از حد نمی سازید. به جای ایجاد خط لوله همزمان با ساخت اپلیکیشن خود، فقط برنامه را بیرون می آورید و سپس آن را سخت می کنید تا مفید بودن آن را ثابت کند. با این حال، همه برنامهها مفید نیستند و همه برنامههای مفید به اندازهای طولانی نیستند که نیاز به سختسازی داشته باشند. بنابراین شما فقط چرخه های مغز ارزشمند خود را صرف برنامه هایی می کنید که هم مفید و هم عمر طولانی دارند.
راه شروع ساده است: شما فقط آن را بسازید
طراحی عمدی
ما دوست داریم فکر کنیم که تصادفی نیست که داستان New Hire در شرکت های مختلف اتفاق می افتد. ما دوست داریم فکر کنیم این داستان اتفاق می افتد زیرا ما به طور عمدی Streamlit را برای ارتقای پیشرفت رو به جلو طراحی می کنیم.
وقتی برای اولین بار شروع به نوشتن یک برنامه می کنید، پیشرفت رو به جلو به این معنی است که یک پیش نویس در 5 دقیقه داشته باشید که قبلاً در آن مفید است برخی راه و یکی از چیزهایی که قطعا یک برنامه را مفیدتر می کند تعامل است. بنابراین، از همان ابتدا، ما این حس قوی را داشتیم که باید تعامل را تا حد امکان ساده کنیم.
به عنوان مثال، شما نباید یک “نما” با یک نوار لغزنده در آن ایجاد کنید، سپس یک “کنترل کننده” با یک تابع تماس که “مدل” استفاده شده توسط لغزنده را تغییر می دهد (به عبارت دیگر، الگوی MVC). در عوض، ما به یک راه حل تک خطی رسیدیم:
value = st.slider("Pick a number", 0, 100)
شما آن را تایپ می کنید و برنامه ای دریافت می کنید که قبلاً کاری انجام می دهد. پیشرفت رو به جلو!
سپس، هنگام ساخت Session State دو سال بعد، به سرعت متوجه شدیم که API پیشنهادی به راحتی منجر به خطاهای یک به یک میشود و تنها راهحلی که جواب داد، callbacks بود. با توجه به تجربیات گذشته خود با MVC و پارادایم های مشابه، مدت زیادی را صرف این مشکل کردیم تا به طور قطعی “Streamlit-y” نسخه ای از تماس های برگشتی که از این همه پیچیدگی جلوگیری می کرد. و – مهمتر از آن – راه حل شما را مجبور به استفاده از تماس های برگشتی از همان ابتدا نمی کند، اما به شما اجازه می دهد تا بعداً در صورت نیاز آنها را لایه لایه کنید. پیشرفت رو به جلو!
نمونه دیگری که برای ما -و قطعاً برای جامعه- عزیز و نزدیک است، استایل است. از یک طرف، ساده ترین کار برای ما این است که به سادگی پشتیبانی از CSS را مستقیماً در Streamlit قرار دهیم، با چیزی شبیه به st.css(...)
یا st.write(..., style="css goes here")
. اما وقتی با آن آزمایش می کنیم، متوجه می شویم که دسترسی نامحدود به یک ظاهر طراحی شده به سرعت تبدیل به یک می شود مانع به سمت پیشرفت رو به جلو به جای ارائه اولین نسخه به سهامداران، مردم در بررسی MDN، مبارزه با آبشار، بهینه سازی انتخابگرها و وسواس در مورد تک پیکسل ها گیر می کنند. و برای تکمیل آن، نتیجه نهایی اغلب پوسته پوسته و حواس پرتی است.
بنابراین ما با پرسیدن این سوالات از خود به این درخواست ها رسیدگی می کنیم:
- “مشکل اساسی که مردم سعی در حل آن دارند چیست؟”
- “این مشکل چقدر رایج است؟”
- “آیا می توانیم خودمان آن را حل کنیم و به آزادسازی توسعه دهنده کمک کنیم؟”
بسته به پاسخ به این سؤالات، یکی از دو رویکرد را دنبال می کنیم:
یک راه حل تک خطی و نظری برای مشکل ارائه دهید
این اتفاق چند ماه پیش افتاد. ما متوجه شدیم که تعداد زیادی از توسعهدهندگان از هکهای CSS برای قرار دادن لوگو در گوشه سمت چپ بالای برنامههای خود استفاده میکنند، بنابراین تصمیم گرفتیم راهحلی تکخطی به آنها بدهیم.
st.logo()
. این دستور جدید لوگوی سفارشی آنها را ترسیم می کند، آن را به وضعیت نوار کناری پاسخ می دهد، مطمئن می شود که با هیچ محتوایی همپوشانی نداشته باشد و فقط به طور پیش فرض خوب به نظر برسد.همچنین به این ترتیب رنگهای متن، خطوط زیر سرصفحه، حاشیههای اطراف کانتینرها، تراز عمودی، آیکونهای Material و غیره را اضافه کردیم. آنها مطمئناً از نظر بصری و رفتار راهحلهای مورد نظر هستند، اما مزیت این است که شما فقط آنچه را که میخواهید میگویید، Streamlit آن را انجام میدهد و به سراغ چیز بعدی میروید. پیشرفت رو به جلو!
مجموعه ای از دستگیره ها را تهیه کنید و تماشا کنید
هنگامی که راه حل تک خطی آن را قطع نمی کند، مجموعه حداقلی از دکمه ها را معرفی می کنیم، نتیجه را مشاهده می کنیم و تکرار می کنیم. از آنجایی که نمی خواهیم سازگاری را از بین ببریم، بیشتر ویژگی های ما درب های یک طرفه هستند، به این معنی که باید با احتیاط پیش برویم.
یک نمونه از این است موضوع بندی. همه میخواهند برنامههایشان با رنگهای شرکتشان مطابقت داشته باشد و البته رنگهای دقیق بسته به شرکت متفاوت است. اما رابط Streamlit از چندین ده رنگ تشکیل شده است و انتخاب یک ترکیب بصری دلپذیر می تواند چندین ساعت زمان ببرد. بنابراین اولین ضربه ما به این مشکل این بود که به شما اجازه دادیم فقط 4 رنگ را انتخاب کنید و Streamlit بقیه رنگ ها را برای شما محاسبه می کند. پیشرفت رو به جلو!
ما اکنون در پشت صحنه مشغول فکر کردن هستیم ضربه دوم در این مشکل – یک راه حل توسعه یافته که به شما دکمه های بیشتری (فراتر از رنگ ها، حتی!) بدون کاهش سرعت تکرار می دهد. به طور مشابه، ما همچنین گزینههای طرحبندی جدید و انعطافپذیرتر را فراتر از ستونها در نظر میگیریم.
فعلا چیزی برای اعلام نداریم، اما حتما حواستون باشه😉
در مجموع، ما نمی خواهیم چیزی شما را از پیشرفت رو به جلو منحرف کند. با هر قدمی که برمیداریم، تمام تلاش خود را میکنیم تا چارچوبی ارائه کنیم که HTML، JS، CSS، HTTP، مسیرها، سریالسازی، تماسهای برگشتی و انواع جزئیات مهندسی را انتزاعی کند. از این طریق، شما می توانید بر روی قرار دادن قدرت داده ها در نوک انگشتان ذینفعان خود تمرکز کنید تا آنها نیز بتوانند پیشرفت رو به جلو.
تکرار باعث کامل شدن می شود
در Streamlit، ما خود از کاربران مشتاق Streamlit هستیم، به این معنی که ما درخواستهای مربوط به حیوانات خانگی خود را داریم. ما نقاط درد شما را به اشتراک می گذاریم، و همیشه در حال تکرار در کتابخانه هستیم. ما هرگز نمی خواهیم تکرار را متوقف کنیم! تعهد ما به این امر در روشی که هر ماه یک نسخه جدید ارسال می کنیم نشان داده می شود.
ما همچنین از جامعه Streamlit و نبوغ شما الهام گرفته ایم. ما دائماً با برنامهها و مؤلفههای سفارشی مواجه میشویم که مرزهای Streamlit را به روشهایی که هرگز فکرش را نمیکردیم جابجا میکنند و به ما ایدههای جدیدی برای چیزهایی میدهند که باید به کتابخانه اصلی بیاوریم. جامعه به راحتی بهترین بخش این کار است!
به همین دلیل، ما چیزهای بیشتری را برای شما آماده کرده ایم. ما در فضای باز توسعه میدهیم، بنابراین همیشه میتوانید نقشه راه ما را در roadmap.streamlit.app بیابید یا در نمایشگاه فصلی بعدی شرکت کنید، جایی که مدیران محصول ما جدیدترینها را در Streamlit، مانند همترازی عمودی و موضوعبندی پیشرفته، مورد بحث قرار میدهند.
زیبایی تکرار این است که بهترین روزها همیشه در پیش هستند. ما خرسندیم که شما را برای سفر همراهی کنیم.
جریان سازی مبارک! 🎈