W grudniu ubiegłego roku zorganizowaliśmy własny hackathon startupów z sześcioma innymi firmami Skolkovo. Bez sponsorów korporacyjnych ani żadnego zewnętrznego wsparcia zebraliśmy dwustu uczestników z 20 rosyjskich miast, wykorzystując wysiłki społeczności programistów. Poniżej opowiem, jak nam się to udało, jakie pułapki napotkaliśmy po drodze i dlaczego natychmiast zaczęliśmy współpracować z jednym ze zwycięskich zespołów.
Interfejs aplikacji sterującej modułami baterii Watts z toru finalistów „Wet Hair”
Spółka
Nasza firma Watts Battery tworzy modułowe przenośne elektrownie. Produktem jest przenośna elektrownia o wymiarach 46x36x11 cm, zdolna do produkcji od 1,5 do 15 kilowatów na godzinę. Cztery takie moduły mogą zapewnić zużycie energii elektrycznej małego domu wiejskiego przez dwa dni.
Chociaż zaczęliśmy wysyłać seryjne próbki w zeszłym roku, Watts Battery jest startupem pod każdym względem. Firma została założona w 2016 roku i od tego roku jest rezydentem Skolkovo Energy Efficient Technologies Cluster. Obecnie mamy 15 pracowników i ogromne zaległości w tym, co chcielibyśmy zrobić na pewnym etapie, ale teraz nie mamy na to czasu.
Obejmuje to również zadania czysto programowe. Dlaczego?
Głównym zadaniem modułu jest zapewnienie nieprzerwanego, zrównoważonego zasilania przy optymalnym koszcie. Jeśli nastąpi przerwa w dostawie prądu z przyczyn niezależnych od Ciebie, zawsze powinieneś mieć zapas, aby w pełni zasilić wymagane obciążenie sieci podczas wyłączania. A gdy wszystko jest w porządku z zasilaniem, możesz użyć energii słonecznej, aby zaoszczędzić.
Najprostszą opcją jest ładowanie akumulatora ze słońca w ciągu dnia i korzystanie z niego wieczorem, ale tylko do niezbędnego poziomu, aby w razie awarii nie zostać bez prądu. W ten sposób nigdy nie znajdziesz się w sytuacji, w której cały wieczór zasilałeś oświetlenie z akumulatora (bo jest taniej), a w nocy prąd został odcięty, a lodówka się rozmroziła.
Oczywiste jest, że człowiek rzadko jest w stanie przewidzieć ilość energii elektrycznej, której potrzebuje, z dużą dokładnością, ale system uzbrojony w model predykcyjny może to zrobić. Dlatego uczenie maszynowe jako takie jest dla nas jednym z priorytetowych obszarów. Po prostu na razie skupiamy się na rozwoju sprzętu i nie możemy przeznaczyć wystarczających zasobów na te zadania, co doprowadziło nas do Startup Hackathon.
Przygotowanie, dane, infrastruktura
Ostatecznie wybraliśmy dwa tory: analitykę danych i system zarządzania. Oprócz naszego było jeszcze siedem torów od kolegów.
Podczas gdy format hackathonu nie był jeszcze zdefiniowany, myśleliśmy o stworzeniu „własnej atmosfery” z systemem punktowym: uczestnicy robią rzeczy, które wydają się nam trudne i interesujące, otrzymując za to punkty. Mieliśmy wiele zadań. Ale w miarę jak budowano strukturę hackathonu, inni organizatorzy poprosili, aby wszystko sprowadzić do wspólnej formy, co zrobiliśmy.
Następnie wymyśliliśmy następujący schemat: chłopaki tworzą model na podstawie swoich danych, a następnie otrzymują nasze dane, których model wcześniej nie widział, uczy się i zaczyna tworzyć prognozy. Zakładano, że wszystko to można zrobić w ciągu 48 godzin, ale dla nas był to pierwszy hackathon na naszych danych i być może przeceniliśmy zasoby czasowe lub stopień gotowości danych. Na specjalistycznych hackathonach dotyczących uczenia maszynowego taki harmonogram byłby normą, ale nasz był inny.
W miarę możliwości usunęliśmy z modułu oprogramowanie i sprzęt, a także przygotowaliśmy wersję naszego urządzenia specjalnie na potrzeby hackathonu, z bardzo prostym i przejrzystym interfejsem wewnętrznym, który mógł obsługiwać każdy programista.
W przypadku toru w systemie sterowania istniała opcja stworzenia aplikacji mobilnej. Aby uczestnicy nie łamali sobie głowy nad tym, jak to powinno wyglądać i nie tracili dodatkowego czasu, daliśmy im projekt aplikacji, superlekki, aby ci, którzy chcieli, mogli po prostu „wyciągnąć” na nią potrzebne im funkcje. Szczerze mówiąc, nie spodziewaliśmy się tutaj żadnych dylematów moralnych, ale jeden z zespołów odebrał to tak, jakbyśmy ograniczali ich lot wyobraźni, chcąc dostać gotowe rozwiązanie za darmo, a nie testować ich w działaniu. I wycofali się.
Inny zespół postanowił stworzyć zupełnie inną aplikację od podstaw i wszystko się udało. Nie nalegaliśmy, aby aplikacja była dokładnie taka, po prostu musiała zawierać pewne elementy, które demonstrują poziom techniczny rozwiązania: wykresy, analizy itp. Gotowy układ projektu był również pewnego rodzaju wskazówką.
Ponieważ analiza modułu Watts Battery na żywo podczas hackathonu zajęłaby zbyt dużo czasu, daliśmy uczestnikom gotowy przekrój danych z miesiąca, pobranych z rzeczywistych modułów naszych klientów (które wcześniej starannie zanonimizowaliśmy). Ponieważ był czerwiec, nie było nic, co mogłoby uwzględnić zmiany sezonowe w analizie. Ale w przyszłości dodamy do nich dane zewnętrzne, takie jak cechy sezonowe i klimatyczne (obecnie jest to standard branżowy).
Nie chcieliśmy tworzyć nierealnych oczekiwań wśród uczestników, więc powiedzieliśmy to wprost w ogłoszeniu hackathonu: praca będzie jak najbardziej zbliżona do pracy w terenie: hałaśliwe, brudne dane, których nikt specjalnie nie przygotował. Ale była też pozytywna strona tego: w duchu agile byliśmy w ciągłym kontakcie z uczestnikami i szybko wprowadzaliśmy zmiany w zadaniu i warunkach przyjęcia (więcej na ten temat poniżej).
Udostępniliśmy również uczestnikom dostęp do Amazon AWS (na tyle aktywnie, że Amazon zablokował jeden region; zastanowimy się, co z tym zrobić). Można tam wdrożyć infrastrukturę IoT i zbudować w pełni funkcjonalne rozwiązanie w ciągu 24 godzin, nawet korzystając z prostych szablonów Amazon. Ostatecznie jednak każdy poszedł swoją drogą, robiąc jak najwięcej samodzielnie. Niektórym udało się zmieścić w limicie czasowym, innym nie. Jeden zespół, Nubble, korzystał z Yandex.Cloud, a pozostali z własnej platformy. hosting Byliśmy nawet skłonni rozdać domeny (sami je zarejestrowaliśmy), ale nie były potrzebne.
Aby wyłonić zwycięzców w analitycznej ścieżce, zaplanowaliśmy porównanie wyników, dla których przygotowaliśmy metryki liczbowe. Ostatecznie jednak nie musieliśmy tego robić, ponieważ z różnych powodów trzech z czterech uczestników nie dotarło do finału.
Jeśli chodzi o infrastrukturę domową, Skolkovo Technopark pomógł nam, udostępniając nam (bezpłatnie) jedną ze swoich przytulnych modułowych sal ze ścianą wideo do prezentacji oraz kilka mniejszych pomieszczeń na część rekreacyjną i do organizacji cateringu.
Analityka
Zadanie: samouczący się system, który identyfikuje anomalie w zużyciu i działaniu modułu na podstawie danych kontrolnych. Celowo pozostawiliśmy sformułowanie tak ogólne, jak to możliwe, aby uczestnicy mogli pomyśleć z nami o tym, co można zrobić na podstawie dostępnych danych.
Swoistość: bardziej złożony z dwóch torów. Dane przemysłowe różnią się nieco od danych w systemach zamkniętych (na przykład marketingu cyfrowego). Tutaj trzeba zrozumieć naturę fizyczną parametrów, które próbujesz analizować; patrzenie na wszystko jako na abstrakcyjne szeregi liczbowe nie zadziała. Na przykład rozkład zużycia energii elektrycznej w ciągu dnia. To jak rytuały: rano w dni powszednie włącza się maszynkę do golenia, a w weekendy mikser. Następnie istota samych anomalii. I nie zapominajmy, że Watts Battery jest przeznaczony do użytku osobistego, więc każdy klient będzie miał swoje własne rytuały, a jeden uniwersalny model nie zadziała. Znalezienie znanych odchyleń w danych nie jest nawet zadaniem, inną rzeczą jest stworzenie systemu, który autonomicznie wyszukuje nieoznakowanych anomalii. W końcu anomalią może być wszystko, w tym podstępny czynnik ludzki. Na przykład w naszych danych testowych był przypadek, gdy system został siłą przełączony na tryb bateryjny przez użytkownika. Bez powodu użytkownicy czasami tak robią (zastrzegam, że ten użytkownik testuje moduł dla nas i z tego powodu ma dostęp do ręcznego sterowania trybami, dla innych użytkowników sterowanie jest całkowicie automatyczne). Jak łatwo przewidzieć, w takiej sytuacji akumulator rozładowuje się dość aktywnie, a jeśli obciążenie jest duże, ładowanie zakończy się przed wschodem słońca lub pojawieniem się innego źródła energii. W takich przypadkach spodziewamy się zobaczyć jakiś rodzaj powiadomienia, że zachowanie systemu odbiega od normy. Albo osoba wyszła, zapomniała wyłączyć piekarnik. System widzi, że zwykle o tej porze dnia pobór wynosi 500 watów, a dziś - 3,5 tysiąca - anomalia! Jak Denis Matsuev w samolocie: „Nic nie rozumiem z silników samolotów, ale w drodze tam silnik brzmiał inaczej”.
Wykres modelu predykcyjnego w sieci neuronowej typu open source Yandex CatBoost
Czego naprawdę potrzebuje firma?: system samodiagnostyki wewnątrz urządzenia, analityka predykcyjna, także bez infrastruktury sieciowej (jak pokazuje praktyka, nie wszyscy nasi klienci spieszą się z podłączaniem baterii do Internetu – większość zadowala się po prostu niezawodną pracą wszystkiego), identyfikacja anomalii, których natury jeszcze nie znamy, samouczący się system bez nauczyciela, klasteryzacja, 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. Na samym hackathonie bardzo ważne było dla nas, aby zobaczyć, że są ludzie gotowi wkroczyć w analitykę przemysłową lub już w niej są i szukają nowych obszarów zastosowań swoich umiejętności. Na początku zaskakujące było, że jest tak wielu chętnych: w końcu to bardzo specyficzna kuchnia, ale stopniowo wszyscy oprócz jednego z czterech uczestników odpadli, więc w pewnym stopniu wszystko się ułożyło.
Dlaczego na tym etapie nie jest to wykonalne?: głównym problemem zadań data mining jest zbyt mała ilość danych. Obecnie na świecie działa kilkadziesiąt urządzeń Watts Battery, ale wiele z nich nie jest podłączonych do sieci, więc nasze dane nie są jeszcze zbyt zróżnicowane. Ledwo udało nam się zebrać dwie anomalie - a te wystąpiły na prototypach, przemysłowe Watts Battery działają dość stabilnie. Gdybyśmy mieli wewnętrznego inżyniera uczenia maszynowego i wiedzielibyśmy - tak, to można wycisnąć z tych danych, a my chcemy uzyskać chłodniejszą jakość predykcji - to byłaby inna historia. Ale do tej pory nic nie zrobiliśmy z tymi danymi. Ponadto wymagałoby to głębokiego zanurzenia uczestników w specyfikę naszego produktu, półtora dnia to za mało.
Jak podjąłeś decyzję?: Nie ustaliliśmy od razu dokładnego zadania końcowego. 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, sfinalizowaliśmy zadanie.
Co otrzymaliśmy w rezultacie?: zwycięzcy toru byli w stanie oczyścić dane (jednocześnie znaleźli „cechy” w obliczeniach niektórych parametrów, których wcześniej nie zauważyliśmy, ponieważ nie wykorzystaliśmy części danych do rozwiązania naszych problemów), zidentyfikować odchylenia od oczekiwanego zachowania modułów Watts Battery i skonfigurować model predykcyjny, który jest w stanie przewidzieć zużycie energii elektrycznej z wysokim stopniem dokładności. Tak, to tylko etap wykonalności opracowywania rozwiązania przemysłowego, potem będą potrzebne tygodnie żmudnej pracy technicznej, ale nawet ten prototyp, stworzony tuż podczas hackathonu, może stanowić podstawę prawdziwego rozwiązania przemysłowego, co jest rzadkością.
główny wniosek: na podstawie danych, które posiadamy, możemy skonfigurować analitykę predykcyjną, założyliśmy to, ale nie mieliśmy zasobów, aby to sprawdzić. Uczestnicy hackathonu sprawdzili i potwierdzili naszą hipotezę, będziemy nadal pracować ze zwycięzcami ścieżki nad tym zadaniem.
Wykres modelu predykcyjnego na sieci neuronowej typu open source Facebook Prophet
Porady na przyszłość: podczas tworzenia zadania należy patrzeć nie tylko na plan produkcji, ale także na zainteresowania uczestników. Ponieważ nasz hackathon nie oferuje nagród pieniężnych, wykorzystujemy naturalną ciekawość naukowców zajmujących się danymi i chęć rozwiązywania nowych, interesujących problemów, w których nikt jeszcze niczego nie pokazał lub w których można pokazać się lepiej niż przy istniejących wynikach. Jeśli od razu weźmiesz pod uwagę czynnik zainteresowania, nie będziesz musiał zmieniać punktu ciężkości po drodze.
Управление
Zadanie: (aplikacja) do zarządzania siecią modułów Watts Battery, z kontem osobistym, przechowywaniem danych w chmurze, monitorowaniem statusu.
Swoistość: w tym utworze nie szukaliśmy jakiegoś nowego rozwiązania technicznego, mamy oczywiście własny interfejs konsumencki. Wybraliśmy go na potrzeby hackathonu, aby zademonstrować możliwości naszego systemu, zagłębić się w niego, sprawdzić zainteresowanie społeczności tematem rozwoju inteligentnych i alternatywnych systemów energetycznych. Aplikację mobilną umieściliśmy jako opcję, można ją było wykonać lub nie według własnego uznania. Ale 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 naprawdę potrzebuje firma?:społeczność programistów, którzy będą wymyślać pomysły biznesowe, testować hipotezy i tworzyć narzędzia do ich wdrażania.
Dlaczego na tym etapie nie jest to wykonalne?:rozmiar rynku jest nadal zbyt mały, aby mogło dojść do organicznego ukształtowania się takiej społeczności.
Jak podjąłeś decyzję?: przeprowadziliśmy pewne badanie fizyczności w ramach hackathonu, czy możliwe jest wymyślenie nie tylko funkcji, ale pełnoprawnych modeli biznesowych wokół naszego bardzo konkretnego produktu. Co więcej, aby mogli to zrobić ludzie zdolni do wdrożenia prototypu, w końcu tutaj – nie chcę nikogo urazić – nie chodzi o poziom programowania migającej diody LED na Arduino (choć można to zrobić za pomocą innowacji), tutaj wymagane są dość specyficzne umiejętności: rozwój systemów back-end i front-end, zrozumienie zasad budowy skalowalnych systemów Internetu Rzeczy.
Co otrzymaliśmy w rezultacie?: dwa zespoły zaproponowały pełnoprawne pomysły biznesowe dla swojej pracy: jeden skupił się bardziej na segmencie rosyjskim, drugi na zagranicznym. Czyli w finale nie tylko opowiedzieli, jak wpadli na pomysł aplikacji, ale w zasadzie zaczęli robić interesy wokół Watts. Chłopaki nakreślili, jak widzą wykorzystanie Watts w kilku modelach biznesowych, podali statystyki, pokazali, w jakich regionach występują problemy, jakie prawa są gdzie przyjmowane, nakreślili globalny trend: niemodne jest wydobywanie bitcoinów, modne jest wydobywanie kilowatów. Celowo przyszli do alternatywnej energii, co bardzo nam się spodobało. Fakt, że uczestnicy, oprócz tego, byli w stanie stworzyć działające rozwiązanie techniczne, sugeruje, że mogą samodzielnie uruchomić startup.
główny wniosek: są zespoły gotowe wziąć Watts Battery za podstawę swojego modelu biznesowego, rozwijać go, zostać partnerami/towarzyszami firmy. Niektóre z nich wiedzą nawet, jak zidentyfikować MVP pomysłu biznesowego i najpierw nad nim popracować, czego brakuje dziś w branży wszędzie. Ludzie nie rozumieją, kiedy przestać, kiedy trzeba wypuścić rozwiązanie na rynek, choćby wczesne, ale działające. W rzeczywistości etap dopracowywania rozwiązania często się nie kończy, rozwiązanie techniczne przekracza granicę rozsądnej złożoności, wchodzi na rynek przeciążone, nie jest już jasne, jaki był pierwotny pomysł, jakie jest targetowanie klientów, jakie są osadzone modele biznesowe. Jak w dowcipie o Akuninie, który napisał kolejną książkę, gdy podpisał poprzednią komuś. A tutaj zrobiono to w czystej postaci: oto wykres, oto licznik, oto wskaźniki, oto prognoza - to wszystko, nic więcej nie jest potrzebne do uruchomienia. Dzięki temu można udać się do inwestora i zdobyć pieniądze na uruchomienie biznesu. Ci, którzy znaleźli tę równowagę, wyszli z toru jako zwycięzcy.
Porady na przyszłość:na kolejnym hackathonie (planujemy to) ), być może warto poeksperymentować również ze sprzętem. Mamy własny rozwój sprzętu (jedna z zalet Wattsa), w pełni kontrolujemy produkcję i testowanie wszystkiego, co robimy, ale brakuje nam zasobów, aby przetestować niektóre hipotezy sprzętowe. Może się okazać, że w społeczności programistów systemowych i niskiego poziomu oraz deweloperów sprzętu znajdą się tacy, którzy pomogą nam w tym i staną się naszymi partnerami w tej dziedzinie w przyszłości.
ludzie
Na hackathonie spodziewaliśmy się raczej tych, którzy chcą spróbować swoich sił w nowej dziedzinie (np. absolwentów różnych szkół programistycznych), a nie tych, którzy specjalizują się w tego typu rozwoju. Ale nadal oczekiwaliśmy, że przed hackathonem wykonają oni pewne prace przygotowawcze, przeczytają o tym, jak generalnie prognozuje się zużycie energii i jak są zorganizowane systemy Internetu Rzeczy. Tak, aby każdy przyszedł nie tylko dla zabawy, dla ciekawych danych i zadań, ale także z wstępnym zanurzeniem się w temacie. 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 API modułów itp.
Poziom technologiczny wszystkich był mniej więcej taki sam, plus minus możliwości. Na tym tle poziom koordynacji nie był najmniej ważnym czynnikiem. Kilka zespołów nie wystartowało, ponieważ nie mogły wyraźnie podzielić się na obszary pracy. Były też takie, w których jedna osoba zajmowała się całym rozwojem, reszta zajmowała się przygotowaniem prezentacji, w innych ktoś dostawał zadania, które wykonywał prawdopodobnie po raz pierwszy w życiu.
Uczestnicy byli w większości młodzi, co nie oznacza, że nie było wśród nich silnych inżynierów uczenia maszynowego i programistów. Większość przyszła w zespołach, praktycznie nie było osób indywidualnych. Każdy marzył o wygranej, niektórzy chcieli znaleźć pracę w przyszłości, około 20% już ją znalazło, myślę, że ta liczba wzrośnie.
Zabrakło nam geeków od sprzętu, ale mamy nadzieję, że uda się to nadrobić podczas drugiego hackathonu.
Postępy hackathonu
Jak pisałem powyżej, większą część 48 godzin hackathonu spędziliśmy z uczestnikami i monitorując ich postępy na punktach kontrolnych, staraliśmy się dostosować zadanie i warunki odbioru pierwszej, analitycznej ścieżki tak, aby z jednej strony uczestnicy mogli ją ukończyć w pozostałym czasie, a z drugiej strony była ona dla nas interesująca.
Ostatnie wyjaśnienie zadania nastąpiło 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 nic nam już nie dało, mieli już gotowe wyniki na podstawie dostępnych danych, a drugiego dnia chłopaki byli już zmęczeni. Postanowiliśmy więc mniej ich męczyć.
Jednak trzech z czterech uczestników nie dotarło do finału. Jeden zespół zorientował się na początku, że bardziej interesuje go utwór naszych kolegów, inny zorientował się tuż przed finałem, że odfiltrował niezbędne dane z wyprzedzeniem podczas przetwarzania i odmówił zaprezentowania swojej pracy.
Zespół „21 (Wet Hair Effect)” uczestniczył w obu naszych ścieżkach do samego końca. Chcieli objąć wszystko na raz: uczenie maszynowe, rozwój, aplikację i stronę internetową. Dopóki nie zagroziliśmy, że ich wycofamy w ostatniej chwili, wierzyli, że mają czas na wszystko, chociaż już na drugim punkcie kontrolnym było oczywiste, że nie udało im się poczynić znaczących postępów w najważniejszej rzeczy – uczeniu maszynowym: generalnie poradzili sobie z drugim blokiem, ale nie byli gotowi przewidzieć zużycia energii elektrycznej. Ostatecznie, gdy zdefiniowaliśmy minimalne zadanie kwalifikujące do pierwszej, nadal wybrali drugą ścieżkę.
Fit-predict miał zbalansowany zespół, skupiony na analizie danych, więc byli w stanie przezwyciężyć wszystko. Było zauważalne, że chłopaki byli zainteresowani „odczuwaniem” prawdziwych danych przemysłowych. Od razu skupili się na najważniejszej rzeczy: analizowali, czyścili dane, radzili sobie z każdą anomalią. Fakt, że byli w stanie zbudować działający model podczas hackathonu, jest wielkim osiągnięciem. W praktyce trwa to zwykle tygodnie: podczas gdy dane są czyszczone, podczas gdy oni się w nie zagłębiają. Więc na pewno będziemy z nimi współpracować.
W drugim torze (zarządzanie) oczekiwaliśmy, że każdy zrobi wszystko w pół dnia i przyjdzie prosić o utrudnienie zadania. W praktyce ledwo udało nam się wykonać podstawowe zadanie. Pracowaliśmy na JS, Pythonie, co odzwierciedla obecny stan branży.
Tutaj także dobrze skoordynowane zespoły osiągnęły wyniki dzięki dobrze ustalonemu podziałowi pracy i jasnemu zrozumieniu, kto za co odpowiada.
Trzeci zespół, FSociety, wydawał się mieć rozwiązanie, ale ostatecznie postanowili nie pokazywać swojego rozwoju, mówiąc, że nie uważali go za działający. Uszanowaliśmy to i nie kłóciliśmy się.
Zwyciężyła drużyna „Strippers from Baku”, która zdołała się powstrzymać, nie gonić za „fajerwerkami”, ale zrobić MVP, którego nie wstyd pokazać i który jasno mówi, że można go dalej rozwijać i skalować. Powiedzieliśmy im od razu: że dodatkowe funkcje nas nie interesują. Jeśli chcą rejestracji przez kod QR, rozpoznawania twarzy, niech najpierw zrobią wykresy w aplikacji, a potem zajmą się opcjonalnymi.
W tym utworze „Wet Hair” pewnie wkroczył do finału, a my rozmawialiśmy o dalszej współpracy z nimi i „Striptease”. Z tym ostatnim spotkaliśmy się już w nowym roku.
Mam nadzieję, że wszystko pójdzie dobrze i czekamy na wszystkich na drugim hackathonie w marcu!
Źródło: www.habr.com
