W grudniu ubiegłego roku wraz z sześcioma innymi firmami Skołkowo zorganizowaliśmy własny hackaton startupowy. Bez sponsorów korporacyjnych ani żadnego wsparcia zewnętrznego, dzięki wysiłkom społeczności programistów zebraliśmy dwustu uczestników z 20 miast Rosji. Poniżej opowiem Wam, jak nam się to udało, jakie pułapki napotkaliśmy po drodze i dlaczego od razu rozpoczęliśmy współpracę z jednym ze zwycięskich zespołów.
Interfejs aplikacji sterującej modułami Watts Battery finalistów utworu „Wet Hair”
spółka
Nasza firma Watts Battery tworzy modułowe przenośne elektrownie. Produkt to przenośna elektrownia o wymiarach 46x36x11 cm, zdolna dostarczyć od 1,5 do 15 kilowatów na godzinę. Cztery takie moduły mogą zapewnić zużycie energii w małym wiejskim domu przez dwa dni.
Chociaż zaczęliśmy wysyłać próbki produkcyjne w zeszłym roku, Watts Battery to startup. Firma powstała w 2016 roku i od tego samego roku jest rezydentem Klastra Technologii Efektywnych Energetycznie Skołkowo.Dziś mamy 15 pracowników i ogromne zaległości w sprawach, które chcielibyśmy kiedyś zrobić, ale na razie nie ma czas na to.
Dotyczy to również zadań czysto programowych. Dlaczego?
Głównym zadaniem modułu jest zapewnienie nieprzerwanych, zrównoważonych dostaw energii przy optymalnych kosztach. Jeśli wystąpi przerwa w dostawie prądu z przyczyn od Ciebie niezależnych, zawsze powinieneś mieć rezerwę, aby w pełni zasilić wymagane obciążenie sieci na czas przerwy. A gdy zasilanie jest dobre, możesz wykorzystać energię słoneczną, aby zaoszczędzić pieniądze.
Najprostszą opcją jest to, że akumulator można ładować ze słońca w ciągu dnia i używać go wieczorem, ale dokładnie do takiego poziomu, jaki jest niezbędny, aby w przypadku braku prądu nie pozostał bez prądu. Nigdy więc nie znajdziesz się w sytuacji, w której przez cały wieczór zasilałeś oświetlenie z akumulatora (bo tak jest taniej), ale w nocy wysiadł prąd i Twoja lodówka się rozmroziła.
Oczywiste jest, że człowiek rzadko jest w stanie przewidzieć z dużą dokładnością ilość potrzebnej mu energii elektrycznej, ale system wyposażony w model predykcyjny może to zrobić. Dlatego uczenie maszynowe jako takie jest jednym z naszych priorytetowych obszarów. Po prostu jesteśmy obecnie skupieni na rozwoju sprzętu i nie możemy przeznaczyć wystarczających zasobów na te zadania, co sprowadziło nas na Startup Hackathon.
Przygotowanie, dane, infrastruktura
W rezultacie obraliśmy dwie ścieżki: analitykę danych i system zarządzania. Oprócz naszego było jeszcze siedem utworów od kolegów.
Choć format hackatonu nie był określony, myśleliśmy o stworzeniu „własnej atmosfery”, z systemem punktowym: uczestnicy wykonują pewne rzeczy, które wydają nam się trudne i interesujące, otrzymując za to punkty. Zadań mieliśmy mnóstwo. Kiedy jednak budowaliśmy strukturę hackatonu, inni organizatorzy poprosili o ujednolicenie wszystkiego, co też zrobiliśmy.
Następnie doszliśmy do następującego schematu: chłopaki tworzą model na podstawie swoich danych, następnie otrzymują nasze dane, których model wcześniej nie widział, uczy się i zaczyna przewidywać. Zakładano, że to wszystko da się zrobić w 48 godzin, jednak dla nas był to pierwszy hackaton na naszych danych i być może przeceniliśmy zasoby czasowe lub stopień gotowości danych. Podczas specjalistycznych hackatonów związanych z uczeniem maszynowym taki harmonogram byłby normą, ale u nas tak nie było.
W miarę możliwości rozładowaliśmy oprogramowanie i sprzęt modułu i stworzyliśmy wersję naszego urządzenia specjalnie na hackaton, z bardzo prostym i zrozumiałym interfejsem wewnętrznym, który może obsłużyć każdy programista.
Dla toru opartego na systemie sterowania istniała możliwość wykonania aplikacji mobilnej. Aby uniemożliwić uczestnikom zawracanie sobie głowy zastanawianiem się, jak to powinno wyglądać i marnowaniem dodatkowego czasu, daliśmy im projektowy układ aplikacji, super lekki, aby ci, którzy tego chcą, mogli po prostu „rozciągnąć” na niego potrzebne funkcje . Szczerze mówiąc, nie spodziewaliśmy się tutaj żadnych dylematów moralnych, ale jeden z zespołów podszedł do tego w taki sposób, że ograniczaliśmy ich lot fantazji, chcieliśmy dostać gotowe rozwiązanie za darmo, a nie je testować w praktyce. I odlecieli.
Inny zespół zdecydował się na stworzenie zupełnie innej aplikacji od zera i wszystko się udało. Nie nalegaliśmy, aby aplikacja była dokładnie taka, zależało nam tylko, aby zawierała pewne elementy obrazujące poziom techniczny rozwiązania: wykresy, analitykę itp. Podpowiedzią był także gotowy układ projektu.
Ponieważ analiza działającego modułu Watts Battery podczas hackatonu byłaby zbyt czasochłonna, daliśmy uczestnikom gotowy fragment danych za miesiąc pobrany z rzeczywistych modułów naszych klientów (które wcześniej starannie zanonimizowaliśmy). Ponieważ był czerwiec, nie było podstaw do uwzględnienia w analizie zmian sezonowych. Ale w przyszłości dodamy do nich dane zewnętrzne, takie jak cechy sezonowe i klimatyczne (dziś jest to standard branżowy).
Nie chcieliśmy budzić wśród uczestników nierealistycznych oczekiwań, dlatego w zapowiedzi hackatonu wprost powiedzieliśmy: praca będzie jak najbardziej zbliżona do pracy w terenie: zaszumione, brudne dane, których nikt specjalnie nie przygotował. Ale miało to też dobrą stronę: w duchu agile byliśmy w stałym kontakcie z uczestnikami i na bieżąco wprowadzaliśmy zmiany w zadaniu i warunkach przyjęć (więcej o tym poniżej).
Dodatkowo daliśmy uczestnikom dostęp do Amazon AWS (na tyle aktywnie, że Amazon zablokował nam jeden region, zastanowimy się co z tym zrobić). Tam możesz wdrożyć infrastrukturę dla Internetu Rzeczy i w oparciu o nawet proste szablony Amazona w ciągu jednego dnia stworzyć pełnoprawne rozwiązanie. Ale ostatecznie absolutnie wszyscy poszli swoją drogą, robiąc wszystko samodzielnie, maksymalnie. Jednocześnie niektórym udało się dotrzymać terminu, innym nie. Jeden zespół, Nubble, korzystał z Yandex.cloud, ktoś wspomniał o tym na ich hostingu. Byliśmy nawet gotowi dać domeny (zarejestrowaliśmy), ale nie były one przydatne.
Aby wyłonić zwycięzców w ścieżce analitycznej, planowaliśmy porównać wyniki, dla których przygotowaliśmy metryki liczbowe. Ale ostatecznie nie było to konieczne, ponieważ z różnych powodów trzech z czterech uczestników nie dotarło do finału.
Jeśli chodzi o infrastrukturę domową, pomógł nam w tym Skołkowo Technopark, udostępniając nam (bezpłatnie) jedną ze swoich przytulnych sal modułowych ze ścianą wideo do prezentacji oraz kilka mniejszych pomieszczeń do rekreacji i organizacji cateringu.
Analityka
Zadanie: system samouczący się, identyfikujący anomalie w zużyciu i pracy modułu na podstawie danych kontrolnych. Celowo utrzymaliśmy sformułowanie tak ogólne, jak to możliwe, aby uczestnicy mogli wspólnie z nami zastanowić się, co można zrobić w oparciu o dostępne dane.
Swoistość: Bardziej złożony z dwóch utworów. Dane przemysłowe różnią się pewnymi cechami od danych w systemach zamkniętych (na przykład marketing cyfrowy). Tutaj musisz zrozumieć fizyczną naturę parametrów, które próbujesz analizować; patrzenie na wszystko jako abstrakcyjne szeregi liczbowe nie będzie działać. Na przykład rozkład zużycia energii elektrycznej w ciągu dnia. To jak rytuały: w dni powszednie rano włącza się elektryczną maszynkę do golenia, a w weekendy włącza się mikser. Następnie istota samych anomalii. I nie zapominaj, że Watts Battery jest przeznaczony do użytku osobistego, więc każdy klient będzie miał swoje własne rytuały i jeden uniwersalny model nie będzie działał. Znalezienie znanych anomalii w danych nie jest nawet zadaniem; stworzenie systemu, który autonomicznie wyszukuje nieoznakowane anomalie, to inna sprawa. W końcu wszystko może być anomalią, łącznie z podstępnym czynnikiem ludzkim. Przykładowo, w naszych danych testowych odnotowano przypadek, w którym użytkownik wymusił przejście systemu w tryb bateryjny. Użytkownicy czasami tak robią (zastrzegam, że ten użytkownik testuje moduł dla nas i dlatego ma dostęp do ręcznego sterowania trybami; dla pozostałych użytkowników sterowanie odbywa się całkowicie automatycznie). Jak łatwo przewidzieć, w takiej sytuacji akumulator rozładowuje się dość aktywnie, a przy dużym obciążeniu ładowanie zakończy się przed wschodem słońca lub pojawieniem się innego źródła energii. W takich przypadkach spodziewamy się powiadomienia o tym, że zachowanie systemu odbiega od normalnego. Albo osoba wyszła i zapomniała wyłączyć piekarnik. System widzi, że zwykle o tej porze pobór wynosi 500 watów, ale dziś - 3,5 tys. - anomalia! Jak Denis Matsuev w samolocie: „Nie rozumiem nic na temat silników lotniczych, ale w drodze na miejsce silnik brzmiał inaczej”.
Wykres modelu predykcyjnego w sieci neuronowej open source Yandex CatBoost
Czego tak naprawdę potrzebuje firma?: system autodiagnostyki wewnątrz urządzenia, analityka predykcyjna, także bez infrastruktury sieciowej (jak pokazuje praktyka, nie wszystkim naszym klientom spieszy się z podłączaniem akumulatorów do Internetu – większości wystarczy, że wszystko po prostu będzie działać niezawodnie), identyfikacja anomalii, których natury jeszcze nie znamy, system samouczący się bez nauczyciela, klastrowanie, sieci neuronowe i cały arsenał nowoczesnych metod analitycznych. Musimy zrozumieć, że system zaczął zachowywać się inaczej, nawet jeśli nie wiemy, co dokładnie się zmieniło. Podczas samego hackathonu bardzo ważne było dla nas, aby zobaczyć, że są ludzie, którzy są gotowi lub już wkroczyli w analitykę przemysłową i szukają nowych obszarów, w których mogliby zastosować swoje umiejętności. Na początku zdziwiłem się, że było tak wielu chętnych: w końcu to bardzo specyficzna kuchnia, ale stopniowo wszyscy z czwórki uczestników oprócz jednego odpadli, więc w pewnym stopniu wszystko się ułożyło.
Dlaczego na tym etapie nie jest to wykonalne?: Głównym problemem związanym z eksploracją danych jest niewystarczająca ilość danych. Na całym świecie działa dziś kilkadziesiąt urządzeń Watts Battery, jednak wiele z nich nie jest podłączonych do sieci, więc nasze dane nie są jeszcze bardzo zróżnicowane. Ledwo udało nam się zebrać w całość dwie anomalie - i te wystąpiły w prototypach; przemysłowa bateria Watts Battery działa w miarę stabilnie. Gdybyśmy mieli wewnętrznego inżyniera zajmującego się uczeniem maszynowym i wiedzieliśmy – tak, da się to wycisnąć z tych danych, ale chcemy uzyskać lepszą jakość przewidywania – to byłaby inna historia. Ale do tego momentu nie zrobiliśmy nic z tymi danymi. Dodatkowo wymagałoby to głębokiego zanurzenia uczestników w specyfice działania naszego produktu, na to półtora dnia nie wystarczy.
Jak zdecydowałeś?: Nie od razu ustalili dokładne ostateczne zadanie. Zamiast tego przez całe 48 godzin prowadziliśmy dialog z uczestnikami, szybko dowiadując się, co udało im się uzyskać, a czego nie. Na tej podstawie, w duchu kompromisu, zadanie zostało sfinalizowane.
Co otrzymałeś w rezultacie?: zwycięzcy utworu byli w stanie oczyścić dane (jednocześnie odkryli „funkcje” obliczania niektórych parametrów, których sami wcześniej nie zauważyliśmy, ponieważ nie wykorzystaliśmy niektórych danych do rozwiązania naszych problemów) , podkreślić odchylenia od oczekiwanego zachowania modułów Watts Battery i stworzyć model predykcyjny, który będzie w stanie przewidzieć zużycie energii z dużą dokładnością. Tak, to dopiero etap wykonalności opracowania rozwiązania przemysłowego, później potrzebne będą tygodnie żmudnej pracy technicznej, ale nawet ten prototyp, powstały bezpośrednio podczas hackatonu, może stanowić podstawę prawdziwego rozwiązania przemysłowego, co zdarza się rzadko.
główny wniosek: Na podstawie posiadanych danych możliwe jest skonfigurowanie analiz predykcyjnych, zakładaliśmy to, ale nie mieliśmy zasobów, aby to sprawdzić. Uczestnicy hackathonu przetestowali i potwierdzili naszą hipotezę, a my będziemy kontynuować współpracę ze zwycięzcami tras w tym zadaniu.
Wykres modelu predykcyjnego w sieci neuronowej Facebook Prophet typu open source
Rady na przyszłość: opracowując zadanie, należy wziąć pod uwagę nie tylko plan produkcji, ale także zainteresowania uczestników. Ponieważ nasz hackaton nie przewiduje nagród pieniężnych, bazujemy na naturalnej ciekawości data sciences i chęci rozwiązania nowych, ciekawych problemów, w których nikt jeszcze niczego nie pokazał lub gdzie mogą pokazać się lepiej niż dotychczasowe wyniki. Jeśli od razu weźmiesz pod uwagę czynnik zainteresowania, nie będziesz musiał po drodze zmieniać swojej uwagi.
Управление
Zadanie: (aplikacja) zarządzająca siecią modułów Watts Battery, z kontem osobistym, przechowywaniem danych w chmurze i monitorowaniem stanu.
Swoistość: w tym utworze nie szukaliśmy jakiegoś nowego rozwiązania technicznego, mamy oczywiście własny interfejs konsumencki. Wybraliśmy go na hackaton, aby zademonstrować możliwości naszego systemu, zanurzyć się w nim i sprawdzić, czy społeczność jest zainteresowana tematem rozwoju inteligentnych systemów i alternatywnych źródeł energii. Jako opcję umieściliśmy aplikację mobilną, możesz to zrobić lub nie, według własnego uznania. Jednak naszym zdaniem dobrze pokazuje, jak ludziom udało się zorganizować przechowywanie danych w chmurze, z dostępem z kilku różnych źródeł jednocześnie.
Czego tak naprawdę potrzebuje firma?: społeczność programistów, którzy będą wymyślać pomysły biznesowe, testować hipotezy i tworzyć działające narzędzia do ich realizacji.
Dlaczego na tym etapie nie jest to wykonalne?: Wielkość rynku jest wciąż zbyt mała, aby organicznie utworzyć taką wspólnotę.
Jak zdecydowałeś?: W ramach hackatonu przeprowadziliśmy swego rodzaju badanie fizyczności, aby sprawdzić, czy możliwe jest opracowanie nie tylko funkcji, ale także pełnoprawnych modeli biznesowych wokół naszego bardzo specyficznego produktu. Co więcej, aby osoby zdolne do wykonania prototypu mogły to jednak zrobić tutaj - nie chcę nikogo urazić - to nie jest poziom programowania migającej diody na Arduino (choć da się to zrobić innowacjami) , wymagane są tu dość specyficzne umiejętności: tworzenie systemów backendowych i frontendowych, zrozumienie zasad budowy skalowalnych systemów Internetu Rzeczy.
Co otrzymałeś w rezultacie?: dwa zespoły zaproponowały pełnowartościowe pomysły biznesowe na swoją pracę: jeden skupił się bardziej na segmencie rosyjskim, drugi na zagranicznym. Oznacza to, że w finale nie tylko opowiedzieli, jak wymyślili aplikację, ale przede wszystkim zaczęli robić interesy wokół Watts. Chłopaki opowiedzieli, jak widzą wykorzystanie Wattów w kilku modelach biznesowych, podali statystyki, pokazali, które regiony mają jakie problemy, jakie przepisy gdzie są uchwalane, nakreślili światowy trend: wydobywanie bitcoinów jest niemodne, modne jest wydobywanie kilowatów. Celowo przeszli na alternatywną energię, co nam się bardzo spodobało. Fakt, że uczestnicy oprócz tego potrafili stworzyć działające rozwiązanie techniczne sugeruje, że mogą samodzielnie uruchomić startup.
główny wniosek: Istnieją zespoły gotowe przyjąć Watts Battery jako podstawę swojego modelu biznesowego, rozwinąć go i stać się partnerami/towarzyszami firmy. Niektórzy z nich wiedzą nawet, jak zidentyfikować MVP pomysłu na biznes i najpierw nad nim pracować, a tego brakuje dziś wszędzie w branży. Ludzie nie rozumieją, kiedy przestać, kiedy wypuścić na rynek rozwiązanie, choć wczesne, ale działające. Tak naprawdę etap dopracowywania rozwiązania często się nie kończy, technicznie rozwiązanie przekracza granicę rozsądnej złożoności, wchodzi na rynek przeciążone, nie jest już jasne, jaki był pierwotny pomysł, jakie jest targetowanie klienta, jakie są modele biznesowe dołączony. Jak w dowcipie o Akuninie, który napisał kolejną książkę, podpisując dla kogoś poprzednią. Ale tutaj zostało to zrobione w najczystszej formie: tutaj jest wykres, tutaj jest licznik, tutaj są wskaźniki, tutaj jest prognoza – to wszystko, nic więcej nie jest potrzebne do jego uruchomienia. Dzięki temu możesz udać się do inwestora i otrzymać pieniądze na rozpoczęcie działalności gospodarczej. Ci, którym udało się znaleźć tę równowagę, opuścili tor jako zwycięzcy.
Rady na przyszłość: na kolejnym hackatonie (planujemy ), być może warto poeksperymentować ze sprzętem. Mamy własny rozwój sprzętu (jedna z zalet Watts), w pełni kontrolujemy produkcję i testowanie wszystkiego, co robimy, ale nie mamy wystarczających zasobów, aby przetestować niektóre hipotezy „sprzętowe”. Bardzo możliwe, że w środowisku programistów systemowych i niskopoziomowych oraz programistów hardware'u znajdą się tacy, którzy nam w tym pomogą i w przyszłości staną się naszym partnerem w tym obszarze.
ludzie
Na hackatonie spodziewaliśmy się raczej tych, którzy chcą spróbować swoich sił w nowej dziedzinie (np. absolwenci różnych szkół programowania), a nie tych, którzy specjalizują się w tego rodzaju rozwoju. Mimo to spodziewaliśmy się, że przed hackatonem wykonają małe prace przygotowawcze, przeczytają o tym, jak w ogóle prognozuje się zużycie energii i jak działają systemy Internetu Rzeczy. Tak, aby każdy przyszedł nie tylko dla zabawy, w poszukiwaniu ciekawych danych i zadań, ale także ze wstępnym zanurzeniem się w tematykę. Z naszej strony rozumiemy, że w tym celu konieczne jest wcześniejsze opublikowanie dostępnych danych, ich opisu i bardziej precyzyjnych wymagań dotyczących wyniku, opublikowanie modułów API itp.
Wszyscy mieli w przybliżeniu ten sam poziom technologiczny, plus minus te same możliwości. Na tym tle poziom harmonii nie był ostatnim czynnikiem. Wiele drużyn nie strzelało, ponieważ nie potrafiły jasno podzielić się na obszary pracy. Bywały też takie, w których całą developmentą zajmowała się jedna osoba, reszta była zajęta przygotowywaniem prezentacji, w innych ktoś dostawał zadania, które wykonywał prawdopodobnie po raz pierwszy w życiu.
Większość uczestników była młoda, nie oznacza to jednak, że nie było wśród nich silnych inżynierów i programistów zajmujących się uczeniem maszynowym. Większość przybyła w zespołach, praktycznie nie było indywidualności. Każdy marzył o wygranej, ktoś chciał w przyszłości znaleźć pracę, około 20% już ją znalazło, myślę, że ta liczba będzie rosła.
Brakowało nam sprzętowych maniaków, ale mamy nadzieję to nadrobić na drugim hackatonie.
Postęp hackathonu
Jak pisałem powyżej, przez większość 48 godzin hackatonu byliśmy z uczestnikami i monitorując ich sukcesy na punktach kontrolnych, staraliśmy się dostosować zadanie i warunki przyjęcia pierwszej, analitycznej ścieżki tak, aby z jednej strony uczestnicy mogli go ukończyć w pozostałym czasie, a z drugiej strony było to dla nas interesujące.
Ostatnie wyjaśnienia zadania miały miejsce gdzieś w okolicach ostatniego punktu kontrolnego, w sobotnie popołudnie (finał zaplanowano na niedzielny wieczór). Uprościliśmy wszystko jeszcze bardziej: usunęliśmy wymóg przeliczania modelu na nowych danych, pozostawiając dane, z którymi zespoły już pracowały. Porównywanie metryk już nic nam nie dało, mieli już gotowe wyniki na podstawie dostępnych danych, a na drugi dzień chłopaki byli już zmęczeni. Dlatego postanowiliśmy mniej ich torturować.
Jednak trzech z czterech uczestników nie dotarło do finału. Jeden zespół już na starcie zorientował się, że bardziej interesuje go trasa naszych kolegów, drugi tuż przed finałem zorientował się, że w trakcie przetwarzania zawczasu odfiltrował niezbędne dane i odmówił zaprezentowania swojej pracy.
W obu naszych utworach ekipa „21 (Wet Hair Effect)” uczestniczyła do samego końca. Chcieli objąć wszystko na raz: uczenie maszynowe, programowanie, aplikacje i stronę internetową. Dopóki w ostatniej chwili nie zagroziliśmy im wycofaniem się, wierzyli, że robią wszystko na czas, choć już na drugim punkcie kontrolnym było oczywiste, że w kwestii najważniejszej – uczenia maszynowego – nie mogli poczynić znaczących postępów: generalnie radzili sobie z drugi blok, ale nie mógł przewidzieć, że zużycie energii elektrycznej nie będzie gotowe. W rezultacie, gdy ustaliliśmy minimalne zadanie do zakwalifikowania się do pierwszego, nadal wybierali drugi tor.
Fit-predict miał zrównoważony skład dostosowany do analizy danych, dzięki czemu był w stanie przezwyciężyć wszystko. Można było zauważyć, że chłopaki byli zainteresowani „dotknięciem” prawdziwych danych przemysłowych. Od razu skupili się na najważniejszej rzeczy: analizie, czyszczeniu danych, radzeniu sobie z każdą anomalią. Wielkim osiągnięciem jest to, że podczas hackatonu udało im się zbudować działający model. W praktyce zajmuje to zwykle tygodnie: podczas czyszczenia danych i zagłębiania się w nie. Dlatego na pewno będziemy z nimi współpracować.
W drugiej ścieżce (zarządzanie) spodziewaliśmy się, że wszyscy zrobią wszystko w pół dnia i przyjdą i poproszą o utrudnienie zadania. W praktyce na wykonanie podstawowego zadania ledwo zdążyliśmy. Pracowaliśmy na JS i Pythonie, co odzwierciedla obecny stan branży.
Tutaj także rezultaty osiągnięto dzięki zgranym zespołom, w których budowano podział pracy, było jasne, kto co robi.
Trzeci zespół, FSociety, wydawał się mieć rozwiązanie, ale ostatecznie zdecydował się nie pokazywać swojego rozwoju, stwierdził, że nie uważa tego za skuteczne. Szanujemy to i nie kłócimy się.
Zwyciężyła drużyna „Strippersy z Baku”, która potrafiła się powstrzymać, nie gonitwą za „błyskotkami”, ale stworzeniem MVP, który nie wstydzi się pokazywać i który jest jasny, że można go dalej rozwijać i skalować. Od razu powiedzieliśmy im, że nie jesteśmy zbytnio zainteresowani dodatkowymi możliwościami. Jeśli chcą rejestracji poprzez kod QR, rozpoznawanie twarzy, niech najpierw zrobią wykresy w aplikacji, a potem zajmą się opcjonalnymi.
W tym utworze „Wet Hair” pewnie wszedł do finału i rozmawialiśmy z nimi o dalszej współpracy z „Hustlers”. Z tym ostatnim spotkaliśmy się już w nowym roku.
Mam nadzieję, że wszystko się ułoży i nie możemy się doczekać, aż zobaczymy się wszyscy na drugim marcowym hackatonie!
Źródło: www.habr.com