그냥 만들어 보세요: 앞으로의 발전 방향으로 편향되도록 Streamlit을 설계하는 방법

원래 Thiago Teixeira의 Streamlit 블로그에 게시됨

이 글을 읽고 계시다면 이미 Streamlit에 대해 잘 알고 계실 것입니다. 그렇지 않다면 요약하자면 다음과 같습니다. Streamlit은 데이터 앱 구축을 위한 Python 프레임워크입니다. 독선적이고, 배터리가 포함되어 있으며, 특정 디자인 시스템과 깊이 연관되어 있습니다.

• 데이터 앱에 중점을 두고 있습니다. 우리가 하는 모든 일은 여기서 비롯됩니다. 우리는 휴대폰에 있는 앱이나 즐겨 사용하는 SaaS와 같은 일반 앱을 대상으로 하지 않지만, 데이터 과학자와 ML 엔지니어가 자신의 작업을 조직에 영향력 있게 만드는 데 필요한 종류의 앱을 대상으로 합니다.
• 독단적입니다. 우리는 빠르고 반복적인 워크플로를 장려하고 엔지니어링 분야의 모범 사례라고 생각하는 것을 유지하고자 하기 때문입니다.
• 배터리가 포함되어 있습니다 시작하는 데 필요한 대부분의 물건은 도서관 자체에 있습니다.
• 마지막으로 디자인 시스템과 연결되어 구성요소 라이브러리, 시각적 언어 또는 아이덴티티를 구축하는 데 시간을 낭비하지 않아도 됩니다. 이제 막 시작하면 빠르게.

이쯤 되면 Streamlit을 어떻게 시작하게 되었는지 말씀드릴 수 있겠네요. 이전의 산학계에서의 경험을 바탕으로 좋은 예감에서 어떻게 시작되었는지에 대해 설명합니다. Streamlit을 형성하기 위해 다양한 회사에 어떻게 깊이 관여하고 데이터 과학자와 ML 엔지니어가 직장에서 관찰했는지에 대해 설명합니다. 하지만 아드리앙은 5년 전에 이미 그 일을 아주 잘 해냈고, 나는 도저히 그 일을 넘을 수 없을 것 같아요!

그 대신 데이터 앱에 대한 우리의 깊은 관심이 우리가 매일 내리는 제품 결정으로 어떻게 전환되는지에 대해 이야기하겠습니다. 이를 위해 이야기부터 시작하겠습니다…

10배의 신규 채용

옛날 옛적에 데이터 과학 팀은 회사의 가장 중요한 지표에 대한 강력한 예측 모델을 구축했습니다. 재무팀은 이를 보고 마음에 들었고 주간 회의에서 사용할 수 있는 라이브 버전을 요청했습니다. 그래서 데이터팀은 도구팀에 데이터 앱 구축을 요청했고, 도구팀은 이를 대기열에 추가했습니다.

3개월이 지나고 많은 회의를 거쳐 앱이 배송됐고 정말 아름다웠습니다.

하지만 한 가지 문제가 있었습니다. Finance에서 이를 시도했을 때 필요한 수준이 아니었습니다. 그래서 그들은 데이터 팀에 또 다른 요청을 제출했고, 데이터 팀은 이를 도구 팀에 전달했고 도구 팀은 이를 대기열에 넣었습니다. 몇 달이 지났습니다.

그 시점에서 아무것도 모르는 신입 사원이 데이터 팀에 합류하여 시작 프로젝트를 맡게 되었습니다. 재무 팀이 도구 팀에서 실제 앱을 기다리는 동안 차단을 해제하기 위해 빠른 데이터 앱을 구성하는 것입니다. .

신입 직원은 인터넷 검색 끝에 Streamlit을 발견했고 하루 만에 최소한의 앱을 동료들과 공유할 수 있었습니다. 완벽하지는 않았지만 일부 피드백을 해결하고 앱을 업데이트했습니다. 다음날 그녀는 이를 재무팀 담당자에게 보여주고 더 많은 피드백을 받아 이에 따라 앱을 개선했습니다.

3일 이내에 재무팀은 회의에서 정기적으로 앱을 사용하게 되었습니다. 더 많은 피드백이 있었고 신입 직원은 최신 버전에서 신속하게 이를 해결했습니다.

일주일 만에 CEO가 앱을 사용하게 되었고, 신입사원은 영웅으로 환호를 받았습니다 ?

왜 이런 일이 발생합니까?

우리는 그 이야기가 일어나는 것을 수없이 보아왔습니다. 결국 신입사원의 앱이 승리하는 이유는 3개월 뒤 과하게 디자인한 앱보다 오늘의 간단한 앱이 낫기 때문입니다.

사실 이것이 바로 최고의 스타트업이 제품을 만드는 방법입니다! MVP(최소 실행 가능 제품)를 출시하고 가능한 한 빨리 고객에게 제공하며 끊임없이 반복합니다.

그리고 그 과정에서 기본 인프라가 점진적으로 강화됩니다. 신입 사원의 이야기에는 다음과 같은 필연적인 결과가 있기 때문입니다. 팀이 앱을 계속 사용하면서 점차적으로 앱을 제작하게 됩니다.

매우 느린 맞춤형 판다 변신 세트인가요? 이를 별도의 데이터 파이프라인과 일부 구체화된 테이블로 가져옵니다.

다른 앱에서도 사용하고 싶은 복잡한 계산이요? 그들은 그것을 RESTful 서비스로 옮깁니다. 앱이 성장함에 따라 앱을 여러 페이지로 리팩터링합니다. 테스트를 작성하고 CI를 설정합니다. 그리고 앱은 방탄이 됩니다.

이 흐름의 이점은 분명합니다.

1. 더 나은 앱을 구축합니다 시도해 보기 전까지는 무엇이 필요한지 알 수 없는 경우가 많기 때문입니다. 따라서 빌드하고 사용자 테스트하고 다시 빌드하고 사용자 테스트하면 모든 것을 미리 계획했지만 뒤늦게 생각했던 솔루션이 아니라는 것을 깨달은 것보다 더 나은 앱을 얻게 됩니다.
2. 첫 날부터 가치를 얻습니다. 구축하고 사용자 테스트를 하면서 이미 유용한 앱을 갖게 됩니다. 그리고 그 과정에서 점점 더 유용해집니다.
3. 과도하게 빌드하지 마세요. 앱을 빌드하는 동시에 파이프라인을 빌드하는 대신 앱을 꺼내서 유용성이 입증되면 강화하면 됩니다. 그러나 모든 앱이 유용한 것은 아니며 모든 유용한 앱이 강화가 필요할 만큼 오래 지속되는 것은 아닙니다. 따라서 유용하고 오래 지속되는 앱에만 소중한 두뇌 주기를 소비하게 됩니다.

시작하는 방법은 간단합니다. 만들기만 하면 됩니다.

의도적인 디자인

신입사원의 이야기가 다양한 회사에서 일어나는 것은 우연이 아니라고 생각하고 싶습니다. 우리는 앞으로의 발전을 촉진하기 위해 Streamlit을 의도적으로 설계했기 때문에 이런 이야기가 일어난다고 생각하고 싶습니다.

처음 앱 작성을 시작할 때 앞으로 진행한다는 것은 이미 몇 가지 유용한 초안을 5분 안에 만드는 것을 의미합니다. 앱을 더욱 유용하게 만드는 한 가지 요소는 바로 상호작용성입니다. 그래서 우리는 초기부터 상호작용성을 최대한 단순하게 만들어야 한다는 강한 인식을 갖고 있었습니다.

예를 들어, 슬라이더가 포함된 '뷰'를 만든 다음 슬라이더에서 사용하는 '모델'(즉, MVC 패러다임)을 수정하는 콜백 함수가 포함된 '컨트롤러'를 만들 필요는 없습니다. ). 대신 우리는 한 줄짜리 솔루션을 생각해냈습니다:

value = st.slider("숫자 선택", 0, 100)

그것을 입력하면 이미 어떤 기능을 수행하는 앱이 나타납니다. 앞으로 전진하세요!

그런 다음 2년 후 세션 상태를 구축할 때 우리는 제안된 API가 쉽게 off-by-one 오류로 이어질 수 있다는 것과 효과가 있었던 유일한 해결책은 콜백이라는 것을 금방 알게 되었습니다. MVC 및 유사한 패러다임에 대한 과거 경험으로 인해 우리는 모든 복잡성을 피하는 확실히 "Streamlit-y" 버전의 콜백을 생각해 내기 위해 문제에 대해 상당한 시간을 보냈습니다. 그리고 더 중요한 것은 이 솔루션이 처음부터 콜백을 사용하도록 강요하지 않고 나중에 필요에 따라 이를 계층화할 수 있다는 것입니다. 앞으로 전진하세요!

우리와 확실히 커뮤니티에 가깝고 소중한 또 다른 예는 스타일링입니다. 한편으로 우리가 할 수 있는 가장 쉬운 일은 st.css(...) 또는 st.write(..., style="css goes here)와 같은 것을 사용하여 Streamlit에 직접 CSS 지원을 추가하는 것입니다. "). 하지만 이를 실험해 보면 스타일링에 대한 무제한적인 접근이 빠르게 앞으로의 발전을 향한 방해가 된다는 것을 알게 됩니다. 첫 번째 버전을 이해관계자들에게 알리는 대신 사람들은 MDN을 뒤지고, 캐스케이드와 싸우고, 선택기를 조정하고, 단일 픽셀에 집착하는 데 꼼짝 못하게 됩니다. 게다가 최종 결과는 불안정하고 산만한 경우가 많습니다.

그래서 우리는 스스로에게 다음과 같은 질문을 던져 이러한 요청을 해결합니다.

• “사람들이 해결하려는 근본적인 문제는 무엇입니까?”
• “그 문제는 얼마나 흔한가요?”
• "우리가 스스로 해결하고 개발자의 자유를 도울 수 있을까요?"

이러한 질문에 대한 답변에 따라 다음 두 가지 접근 방식 중 하나를 따릅니다.

1. 문제에 대한 한 줄의 독선적인 해결책 제공

   몇 달 전에 이런 일이 일어났습니다. 우리는 수많은 개발자가 CSS 해킹을 사용하여 앱의 왼쪽 상단에 로고를 배치하는 것을 보고 st.logo()를 사용하여 한 줄 솔루션을 제공하기로 결정했습니다. 이 새로운 명령은 사용자 정의 로고를 그리고 사이드바 상태에 반응하도록 하며, 콘텐츠가 겹치지 않도록 하고 기본적으로 보기 좋게 보입니다.

   또한 텍스트 색상, 헤더 아래 선, 컨테이너 주변 테두리, 수직 정렬, 머티리얼 아이콘 등을 추가한 방법이기도 합니다. 시각적 및 행동 측면에서 확실히 독보적인 솔루션이지만 원하는 것을 말하면 Streamlit이 수행하고 다음 단계로 넘어갈 수 있다는 장점이 있습니다. 앞으로 전진하세요!

2. 선별된 손잡이 세트를 제공하고 시청하세요

   한 줄의 독창적인 솔루션이 문제를 해결하지 못하는 경우 최소한의 '손잡이' 세트를 도입하고 결과를 관찰한 후 반복합니다. 호환성을 깨고 싶지 않기 때문에 대부분의 기능이 단방향 도어이므로 주의해서 진행해야 합니다.

   이것의 예로는 테마가 있습니다. 누구나 자신의 앱이 회사의 색상과 일치하기를 원하며, 물론 정확한 색상은 회사마다 다릅니다. 그러나 Streamlit의 인터페이스는 수십 가지 색상으로 구성되어 있어 시각적으로 보기 좋은 조합을 선택하는 데 몇 시간이 걸릴 수 있습니다. 따라서 이 문제에 대한 첫 번째 시도는 사용자가 4가지 색상만 선택하도록 하는 것이었고 Streamlit은 나머지 모든 색상을 계산합니다. 앞으로 전진하세요!

   이제 우리는 이 문제에 대한 두 번째 시도, 즉 반복 속도를 희생하지 않고도 더 많은 노브(색상을 뛰어넘는 것까지!)를 제공하는 확장된 솔루션을 생각하느라 바쁩니다. 마찬가지로 우리는 열 이외의 새롭고 더욱 유연한 레이아웃 옵션도 고려하고 있습니다.

   지금은 알려드릴 내용이 없지만, 꼭 지켜봐주세요 ?

요컨대, 앞으로의 진행에 방해가 되는 어떤 것도 원하지 않습니다. 우리가 취하는 모든 단계에서 우리는 HTML, JS, CSS, HTTP, 경로, 직렬화, 콜백 및 모든 종류의 엔지니어링 세부 사항을 추상화하는 프레임워크를 제공하기 위해 최선을 다합니다. 이렇게 하면 이해관계자가 데이터의 힘을 쉽게 활용할 수 있게 하여 그들도 앞으로 발전할 수 있도록 하는 데 집중할 수 있습니다.

반복이 완벽함을 만든다

Streamlit에서는 Streamlit을 열성적으로 사용하고 있습니다. 즉, 불만 사항과 기능 요청이 있다는 뜻입니다. 우리는 여러분의 문제점을 공유하고 항상 라이브러리에서 반복하고 있습니다. 우리는 반복을 멈추고 싶지 않습니다! 이에 대한 우리의 헌신은 매달 새로운 릴리스를 출시하는 방식으로 입증됩니다.

저희는 Streamlit 커뮤니티와 여러분의 독창성에서도 영감을 받았습니다. 우리는 불가능하다고 생각했던 방식으로 Streamlit의 경계를 넓히는 앱과 사용자 정의 구성 요소를 끊임없이 접하고 핵심 라이브러리에 가져올 항목에 대한 새로운 아이디어를 제공합니다. 커뮤니티는 이 작업의 가장 중요한 부분입니다!

이 때문에 우리는 여러분을 위해 훨씬 더 많은 것을 준비했습니다. 우리는 공개적으로 개발하므로 언제든지 roadmap.streamlit.app에서 로드맵을 확인하거나 다음 분기별 쇼케이스에 참석하여 제품 관리자가 수직 정렬 및 고급 테마 지정과 같은 Streamlit의 최신 내용을 논의할 수 있습니다.

반복의 장점은 최고의 날이 항상 앞에 있다는 것입니다. 여러분과 함께 하게 되어 영광입니다.

행복한 Streamliting을 즐겨보세요! ?

위 내용은 그냥 만들어 보세요: 앞으로의 발전 방향으로 편향되도록 Streamlit을 설계하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!