Kodėl aparatinės įrangos paleidimui reikalingas programinės įrangos hakatonas?

Praėjusį gruodį surengėme savo startuolių hakatoną su kitomis šešiomis Skolkovo įmonėmis. Be įmonių rėmėjų ar jokios išorinės paramos programuotojų bendruomenės pastangomis surinkome du šimtus dalyvių iš 20 Rusijos miestų. Toliau papasakosiu, kaip mums sekėsi, su kokiais spąstais susidūrėme kelyje ir kodėl iš karto pradėjome bendradarbiauti su viena iš laimėjusių komandų.

Kodėl aparatinės įrangos paleidimui reikalingas programinės įrangos hakatonas?Programos, valdančios Watts Battery modulius iš „Wet Hair“ finalininkų, sąsaja

įmonė

Mūsų įmonė Watts Battery kuria modulines nešiojamas elektrines. Gaminys yra nešiojama elektrinė 46x36x11 cm, galinti tiekti nuo 1,5 iki 15 kilovatų per valandą. Keturi tokie moduliai gali užtikrinti mažo kaimo namo energijos suvartojimą dviem dienoms.

Nors gamybos pavyzdžius pradėjome gabenti praėjusiais metais, „Watts Battery“ yra startuolis. Įmonė buvo įkurta 2016 metais ir nuo tų pačių metų yra Skolkovo energetiškai efektyvių technologijų klasterio rezidentė.Šiandien turime 15 darbuotojų ir didžiulį atsilikimą dalykų, kuriuos norėtume atlikti kažkuriame etape, tačiau šiuo metu nėra laiko tam.

Tai taip pat apima grynai programinės įrangos užduotis. Kodėl?

Pagrindinė modulio užduotis – optimaliomis sąnaudomis užtikrinti nepertraukiamą, subalansuotą energijos tiekimą. Jei elektra nutrūksta dėl priežasčių, nepriklausančių nuo jūsų, visada turėtumėte turėti rezervą, kad galėtumėte visiškai maitinti reikiamą tinklo apkrovą tiekimo nutraukimo metu. O kai maitinimas geras, sutaupydami galite naudoti saulės energiją.

Paprasčiausias variantas – bateriją galima įkrauti nuo saulės dienos metu, o naudoti vakare, tačiau tiksliai iki tokio lygio, koks yra būtinas, kad dingus elektrai neliktų be elektros. Taigi, niekada neatsidursite situacijoje, kai visą vakarą maitinote apšvietimą iš baterijos (nes taip pigiau), bet naktį dingo elektra ir atitirpsta šaldytuvas.

Akivaizdu, kad žmogus retai kada sugeba itin tiksliai nuspėti jam reikalingą elektros energijos kiekį, tačiau nuspėjamuoju modeliu apsiginklavusi sistema gali. Todėl mašininis mokymasis yra viena iš mūsų prioritetinių sričių. Tiesiog šiuo metu esame susikoncentravę į aparatinės įrangos kūrimą ir negalime skirti pakankamai išteklių šioms užduotims, todėl mus atvedė į Startup Hackathon.

Parengimas, duomenys, infrastruktūra

Dėl to pasirinkome dvi kryptis: duomenų analitiką ir valdymo sistemą. Be mūsiškių, buvo dar septyni kolegų kūriniai.

Kol hakatono formatas nebuvo nustatytas, galvojome sukurti „savo atmosferą“, su taškų sistema: dalyviai daro kai kuriuos dalykus, kurie mums atrodo sunkūs ir įdomūs, už tai gaudami taškus. Turėjome daug užduočių. Bet mums statant hakatono struktūrą, kiti organizatoriai prašė viską suvesti į bendrą formą, ką ir padarėme.

Tada priėjome prie tokios schemos: vaikinai pagal savo duomenis sukuria modelį, tada gauna mūsų duomenis, kurių modelis anksčiau nebuvo matęs, išmoksta ir pradeda prognozuoti. Buvo manoma, kad visa tai galima padaryti per 48 valandas, tačiau mums tai buvo pirmasis mūsų duomenų įsilaužimas, ir galbūt pervertinome laiko išteklius ar duomenų parengtumo laipsnį. Specializuotuose mašininio mokymosi hakatonuose tokia laiko juosta būtų įprasta, bet pas mus tokia nebuvo.

Kiek įmanoma iškrovėme modulio programinę ir techninę įrangą ir sukūrėme specialiai hakatonui skirtą savo įrenginio versiją su labai paprasta ir suprantama vidine sąsaja, kurią galėtų palaikyti bet kuris kūrėjas.

Trasai, pagrįsta valdymo sistema, buvo galimybė sukurti mobiliąją aplikaciją. Kad dalyviai negalvotų, kaip ji turėtų atrodyti, ir negaištų papildomo laiko, suteikėme jiems itin lengvą dizaino aplikacijos maketą, kad norintys galėtų tiesiog „pritempti“ joje reikalingas funkcijas. . Tiesą pasakius, jokių moralinių dilemų čia nesitikėjome, bet viena iš komandų taip pasielgė, kad apribojome jų fantazijos skrydį, norėjome nemokamai gauti paruoštą sprendimą, o ne išbandyti. praktikoje. Ir jie pakilo.

Kita komanda nusprendė sukurti visiškai kitokią programą nuo nulio, ir viskas pavyko. Nereikalavome, kad programa būtų būtent tokia, tiesiog reikėjo, kad joje būtų keletas elementų, parodančių techninį sprendimo lygį: grafikai, analitika ir pan. Užuomina buvo ir baigtas dizaino išdėstymas.

Kadangi analizuoti tiesioginį Watts Battery modulį hakatone užtruktų per daug laiko, dalyviams suteikėme paruoštą mėnesio duomenų dalį, paimtą iš tikrųjų mūsų klientų modulių (kuriuos iš anksto kruopščiai anonimizavome). Kadangi buvo birželis, į analizę nebuvo ko įtraukti sezoninių pokyčių. Tačiau ateityje prie jų pridėsime išorinius duomenis, pvz., sezonines ir klimatines ypatybes (šiandien tai yra pramonės standartas).

Nenorėjome dalyviams sukurti nerealių lūkesčių, todėl hakatono anonse tiesiai pasakėme: darbas bus kuo artimesnis lauko darbams: triukšmingi, nešvarūs duomenys, kurių niekas specialiai nerengė. Tačiau tai turėjo ir teigiamą pusę: judrumo dvasia nuolat bendravome su dalyviais, operatyviai keitėme užduotį ir priėmimo sąlygas (apie tai plačiau žemiau).

Be to, dalyviams suteikėme prieigą prie „Amazon AWS“ (taip aktyviai, kad „Amazon“ mums užblokavo vieną regioną, sugalvosime, ką su tuo daryti). Ten galite įdiegti daiktų interneto infrastruktūrą ir, remdamiesi net paprastais „Amazon“ šablonais, per dieną sukurti visavertį sprendimą. Bet galiausiai absoliučiai kiekvienas nuėjo savo keliu, viską darydamas savarankiškai. Tuo pačiu metu vieniems pavyko laikytis laiko limito, kitiems – ne. Viena komanda „Nubble“ naudojo „Yandex.cloud“, kažkas iškėlė tai savo priegloboje. Buvome net pasiruošę duoti domenus (turime registruotų), bet jie nebuvo naudingi.

Nugalėtojams analitinėje trasoje nustatyti planavome palyginti rezultatus, kuriems paruošėme skaitines metrikas. Tačiau galiausiai to daryti neprireikė, nes dėl įvairių priežasčių trys iš keturių dalyvių nepateko į finalą.

Kalbant apie buitinę infrastruktūrą, čia padėjo Skolkovo technikos parkas, suteikęs mums (nemokamai) vieną iš savo jaukių modulinių kambarių su vaizdo sienele pristatymams ir porą mažesnių kambarių poilsio zonai bei maitinimui organizuoti.

Analytics "

Užduotis: savarankiškai besimokanti sistema, kuri pagal valdymo duomenis nustato vartojimo ir modulio veikimo anomalijas. Sąmoningai formulavome kuo bendresnę formuluotę, kad dalyviai galėtų kartu su mumis pagalvoti, ką būtų galima padaryti remiantis turimais duomenimis.

Specifiškumas: sudėtingesnis iš dviejų takelių. Pramoniniai duomenys šiek tiek skiriasi nuo uždarų sistemų duomenų (pavyzdžiui, skaitmeninės rinkodaros). Čia reikia suprasti fizinę parametrų, kuriuos bandote analizuoti, prigimtį; žiūrėti į viską kaip į abstrakčias skaičių serijas neveiks. Pavyzdžiui, elektros suvartojimo paskirstymas per dieną. Tai tarsi ritualai: darbo dienomis ryte įjungiamas elektrinis skustuvas, o savaitgaliais – maišytuvas. Tada pačių anomalijų esmė. Ir nepamirškite, kad Watts Battery yra skirtas asmeniniam naudojimui, todėl kiekvienas klientas turės savo ritualus, o vienas universalus modelis netiks. Rasti žinomų duomenų anomalijas net nėra užduotis; kitas dalykas yra sukurti sistemą, kuri savarankiškai ieško nepažymėtų anomalijų. Juk bet kas gali būti anomalija, įskaitant klastingą žmogiškąjį faktorių. Pavyzdžiui, mūsų bandymo duomenyse buvo atvejis, kai vartotojas privertė sistemą įjungti akumuliatoriaus režimą. Be jokios priežasties vartotojai kartais tai daro (pasidarysiu išlygą, kad šis vartotojas testuoja modulį už mus ir dėl šios priežasties jis turi prieigą prie rankinio režimų valdymo, kitiems vartotojams valdymas yra visiškai automatinis). Kaip nesunku nuspėti, tokioje situacijoje baterija gana aktyviai išsikrauna, o jei apkrova didelė, įkrovimas baigsis dar nepatekėjus saulei ar nepasirodžius kitam energijos šaltiniui. Tokiais atvejais tikimės pamatyti tam tikrą pranešimą, kad sistemos elgsena nukrypo nuo įprastos. Arba žmogus išėjo ir pamiršo išjungti orkaitę. Sistema mato, kad dažniausiai tokiu paros metu suvartojimas siekia 500 vatų, tačiau šiandien – 3,5 tūkst. – anomalija! Kaip ir Denisas Matsuevas lėktuve: „Nieko nesuprantu apie orlaivių variklius, bet pakeliui ten variklis skambėjo kitaip.

Kodėl aparatinės įrangos paleidimui reikalingas programinės įrangos hakatonas?Atvirojo kodo neuroninio tinklo „Yandex CatBoost“ nuspėjamojo modelio grafikas

Ko iš tikrųjų įmonei reikia?: savidiagnostikos sistema įrenginio viduje, nuspėjamoji analizė, taip pat ir be tinklo infrastruktūros (kaip rodo praktika, ne visi mūsų klientai skuba jungti baterijas prie interneto – daugumai užtenka, kad viskas veiktų tik patikimai), anomalijų, kurių prigimties dar nežinome, nustatymas, savarankiško mokymosi sistema be mokytojo, grupavimas, neuroniniai tinklai ir visas šiuolaikinių analizės metodų arsenalas. Turime suprasti, kad sistema pradėjo elgtis kitaip, net jei nežinome, kas tiksliai pasikeitė. Pačiame hakatone mums buvo labai svarbu pamatyti, kad yra vaikinų, kurie yra pasiruošę žengti į industrinę analitiką arba jau yra joje, ir jie ieško naujų sričių, kuriose galėtų pritaikyti savo gebėjimus. Iš pradžių nustebau, kad norinčiųjų tiek daug: juk tai labai specifinė virtuvė, bet pamažu visi, išskyrus vieną, iš keturių dalyvių iškrito, tad kažkiek viskas stojo į savo vietas.

Kodėl šiame etape tai neįmanoma?: Pagrindinė duomenų gavybos užduočių problema yra nepakankamas duomenų kiekis. Šiandien visame pasaulyje veikia kelios dešimtys Watts Battery įrenginių, tačiau daugelis jų nėra prijungti prie tinklo, todėl mūsų duomenys dar nėra labai įvairūs. Vos iškrapštėme dvi anomalijas – ir tos, kurios atsirado ant prototipų; pramoninė vatų baterija veikia gana stabiliai. Jei turėtume vidinį mašininio mokymosi inžinierių ir žinotume – taip, tai gali būti išspausta iš šių duomenų, bet norėtume gauti geresnę prognozavimo kokybę – tai būtų viena istorija. Tačiau iki šiol nieko nepadarėme su šiais duomenimis. Be to, tam reikėtų dalyviams giliai pasinerti į mūsų gaminio veikimo specifiką, pusantros paros tam neužtenka.

Kaip nusprendėte?: Jie ne iš karto nustatė tikslią galutinę užduotį. Vietoj to, visas 48 valandas mes bendravome su dalyviais, greitai išsiaiškindami, ką jie galėjo gauti, o ko ne. Remiantis tuo, kompromiso dvasia, užduotis buvo baigta.

Ką gavote dėl to?: trasos nugalėtojai sugebėjo išvalyti duomenis (tuo pačiu jie rado kai kurių parametrų skaičiavimo „ypatybes“, kurių mes patys anksčiau nepastebėjome, nes kai kurių duomenų nepanaudojome savo problemoms spręsti) , paryškinkite nukrypimus nuo numatomo Watts Battery modulių veikimo ir sukurkite nuspėjamąjį modelį, galintį numatyti energijos suvartojimą dideliu tikslumu. Taip, tai tik pramoninio sprendimo kūrimo galimybių etapas, tada prireiks savaičių kruopštaus techninio darbo, tačiau net ir šis prototipas, sukurtas tiesiogiai hakatono metu, gali tapti realaus pramoninio sprendimo pagrindu, o tai retai pasitaiko.

pagrindinė išvada: Remiantis turimais duomenimis, galima nustatyti nuspėjamąją analizę, mes tai manėme, bet neturėjome resursų patikrinti. Hakatono dalyviai patikrino ir patvirtino mūsų hipotezę, o mes ir toliau dirbsime su trasų nugalėtojais.

Kodėl aparatinės įrangos paleidimui reikalingas programinės įrangos hakatonas?Atvirojo kodo neuroninio tinklo „Facebook Prophet“ nuspėjamojo modelio grafikas

Patarimas ateičiai: rengdami užduotį turite atsižvelgti ne tik į savo gamybos planą, bet ir į dalyvių susidomėjimą. Kadangi mūsų hakatonas neturi piniginių prizų, žaidžiame natūraliu duomenų mokslininkų smalsumu ir noru spręsti naujas, įdomias problemas, kuriose niekas dar nieko neparodė arba kur gali pasirodyti geriau nei esami rezultatai. Jei iš karto atsižvelgsite į dominantį veiksnį, jums nereikės perkelti savo dėmesio pakeliui.

Valdymas

Užduotis: (programa), valdanti Watts Battery modulių tinklą su asmenine paskyra, duomenų saugykla debesyje ir būsenos stebėjimu.

Specifiškumas: šioje trasoje mes neieškojome kažkokio naujo techninio sprendimo, mes, žinoma, turime savo vartotojo sąsają. Jį hakatonui pasirinkome norėdami pademonstruoti savo sistemos galimybes, pasinerti į ją ir patikrinti, ar bendruomenei įdomi išmaniųjų sistemų ir alternatyvios energijos kūrimo tema. Mes nustatėme mobiliąją aplikaciją kaip parinktį; galite tai padaryti arba nedaryti savo nuožiūra. Tačiau, mūsų nuomone, tai gerai parodo, kaip žmonėms pavyko sutvarkyti duomenų saugojimą debesyje su prieiga iš kelių skirtingų šaltinių vienu metu.

Ko iš tikrųjų įmonei reikia?: kūrėjų bendruomenė, kuri kurs verslo idėjas, tikrins hipotezes ir kurs darbo įrankius joms įgyvendinti.

Kodėl šiame etape tai neįmanoma?: Rinkos apimtis dar per maža organiškam tokios bendruomenės formavimuisi.

Kaip nusprendėte?: Vykdydami hakatoną atlikome savotišką fiziškumo tyrimą, norėdami išsiaiškinti, ar įmanoma sukurti ne tik funkcijas, bet ir visaverčius verslo modelius, susijusius su mūsų labai specifiniu produktu. Be to, kad žmonės, galintys įdiegti prototipą, tai padarytų, juk čia - nenoriu nieko įžeisti - tai nėra Arduino mirksinčio LED programavimo lygis (nors tai galima padaryti su naujovėmis) , čia reikalingi gana specifiniai įgūdžiai: backend ir frontend sistemų kūrimas, keičiamo dydžio daiktų interneto sistemų kūrimo principų supratimas.

*Antrojo kūrinio nugalėtojų kalba*

Ką gavote dėl to?: pilnavertes verslo idėjas savo darbui pasiūlė dvi komandos: viena daugiau dėmesio skyrė rusiškam segmentui, kita – užsienio. Tai reiškia, kad finale jie ne tik papasakojo, kaip sugalvojo programą, bet iš esmės ėmėsi verslo aplink Watts. Vaikinai išdėstė, kaip mato vatų panaudojimą keliuose verslo modeliuose, pateikė statistiką, parodė, kuriuose regionuose kokių problemų kyla, kokie įstatymai kur priimti, nubrėžė pasaulinę tendenciją: bitkoinus kasti nemadinga, kilovatus – madinga. Jie sąmoningai atėjo į alternatyvią energiją, kuri mums labai patiko. Tai, kad dalyviai, be to, sugebėjo sukurti veikiantį techninį sprendimą, rodo, kad jie gali savarankiškai pradėti startuolį.

pagrindinė išvada: Yra komandos, pasirengusios paimti Watts Battery kaip savo verslo modelio pagrindą, jį plėtoti ir tapti įmonės partneriais/kompanionais. Kai kurie iš jų netgi žino, kaip nustatyti verslo idėjos MVP ir pirmiausia su ja dirbti – to šiandien trūksta visur pramonėje. Žmonės nesupranta, kada sustoti, kada išleisti į rinką sprendimą, nors ir anksti, bet veikiantį. Tiesą sakant, sprendimo poliravimo etapas dažnai nesibaigia, techniškai sprendimas peržengia protingo sudėtingumo ribą, į rinką patenka perkrautas, nebeaišku, kokia buvo pirminė idėja, kas yra orientavimasis į klientą, kokie verslo modeliai. įskaitant. Kaip anekdote apie Akuniną, kuris kažkam pasirašydamas ankstesnėje parašė kitą knygą. Bet čia tai buvo padaryta gryniausia forma: čia yra diagrama, čia yra skaitiklis, čia yra rodikliai, čia yra prognozė - tai viskas, nieko daugiau nereikia, kad jis būtų paleistas. Taip galite kreiptis į investuotoją ir gauti pinigų verslo pradžiai. Tie, kurie rado šią pusiausvyrą, išėjo iš trasos kaip nugalėtojai.

Patarimas ateičiai: kitame hakatone (planuojame šių metų kovo mėnesį), galbūt prasminga eksperimentuoti su aparatine įranga. Mes turime savo techninės įrangos kūrimą (vienas iš Watts privalumų), visiškai kontroliuojame gamybą ir testavimą visko, ką darome, tačiau neturime pakankamai resursų patikrinti kai kurias „aparatinės įrangos“ hipotezes. Gali būti, kad sisteminių ir žemo lygio programuotojų bei techninės įrangos kūrėjų bendruomenėje yra tokių, kurie mums tai padės ir ateityje taps mūsų partneriais šioje srityje.

Žmonės

Hakatone laukėme norinčių išbandyti save naujoje srityje (pavyzdžiui, įvairių programavimo mokyklų absolventų), o ne tokių, kurie specializuojasi tokioje srityje. Bet vis tiek tikėjomės, kad prieš hakatoną jie atliks nedidelį parengiamąjį darbą, pasiskaitys, kaip apskritai prognozuojamas energijos suvartojimas ir kaip veikia daiktų interneto sistemos. Kad visi ateitų ne tik linksmintis, ieškoti įdomių duomenų ir užduočių, bet ir iš anksto įsigilinę į dalykinę sritį. Iš savo pusės suprantame, kad tam būtina iš anksto paskelbti turimus duomenis, jų aprašymą ir tikslesnius reikalavimus rezultatui, publikuoti API modulius ir pan.

Visi turėjo maždaug tokį patį technologinį lygį, plius ar minus tas pačias galimybes. Atsižvelgiant į tai, harmonijos lygis nebuvo paskutinis veiksnys. Nemažai komandų nešaudė, nes negalėjo aiškiai pasiskirstyti į darbo sritis. Buvo ir tokių, kuriose vienas žmogus darė visą kūrimą, likusieji ruošė pristatymą, kituose kažkam buvo duota užduočių, kurias jie atliko, ko gero, pirmą kartą gyvenime.

Dauguma dalyvių buvo jauni, tai nereiškia, kad tarp jų nebuvo stiprių mašininio mokymosi inžinierių ir kūrėjų. Dauguma atvyko komandomis, žmonių praktiškai nebuvo. Visi svajojo laimėti, kažkas norėjo susirasti darbą ateityje, apie 20% jau susirado, manau, kad šis skaičius augs.

Neturėjome pakankamai aparatūros geeks, bet tikimės, kad atsigriebsime per antrąjį hakatoną.

Hakatono progresas

Kaip jau rašiau aukščiau, didžiąją dalį 48 hakatono valandų buvome su dalyviais ir, stebėdami jų sėkmę patikros punktuose, stengėmės pritaikyti užduotį ir sąlygas priimti pirmąją, analitinę trasą taip, kad, viena vertus, dalyviai galėjo jį atlikti per likusį laiką, o kita vertus, tai mus domino.

Paskutinis užduoties patikslinimas buvo atliktas kažkur apie paskutinį kontrolinį punktą, šeštadienio popietę (finalas buvo numatytas sekmadienio vakarą). Viską dar šiek tiek supaprastinome: panaikinome reikalavimą perskaičiuoti modelį pagal naujus duomenis, palikdami duomenis, su kuriais komandos jau dirbo. Metrikų lyginimas mums jau nieko nedavė, jie jau turėjo paruoštus rezultatus pagal turimus duomenis, o antrą dieną vaikinai jau buvo pavargę. Todėl nusprendėme juos mažiau kankinti.

Tačiau trys iš keturių dalyvių į finalą nepateko. Viena komanda jau pradžioje suprato, kad ją labiau domina mūsų kolegų trasa, kita, prieš pat finalą, suprato, kad apdorojimo procese iš anksto išfiltravo reikiamus duomenis ir atsisakė pristatyti savo darbus.

„21 (Wet Hair Effect)“ komanda abiejose mūsų trasose dalyvavo iki pat pabaigos. Jie norėjo aprėpti viską iš karto: mašininį mokymąsi, kūrimą, taikymą ir svetainę. Kol paskutinę akimirką negrasinome jiems pasitraukimu, jie tikėjo, kad viską daro laiku, nors jau antrajame patikros punkte buvo akivaizdu, kad su pagrindiniu dalyku - mašininiu mokymusi - jie negalėjo padaryti didelės pažangos: jie apskritai susidorojo su problema. antrojo bloko, tačiau negalėjo numatyti elektros suvartojimo, nebuvo pasiruošę. Dėl to, kai nustatėme minimalią užduotį norint patekti į pirmąjį, jie vis tiek pasirinko antrąjį takelį.

„Fit-predict“ turėjo subalansuotą sudėtį, pritaikytą duomenų analizei, todėl jie galėjo įveikti viską. Pastebėta, kad vaikinams buvo įdomu „paliesti“ tikrus pramonės duomenis. Jie iškart susikoncentravo ties pagrindiniu dalyku: duomenų analize, valymu, kiekvienos anomalijos tvarkymu. Tai, kad hakatono metu pavyko sukurti veikiantį modelį, yra didelis pasiekimas. Darbo praktikoje tai dažniausiai užtrunka savaites: kol duomenys valomi, kol į juos gilinasi. Todėl tikrai su jais dirbsime.

Antrame takelyje (vadyboje) tikėjomės, kad visi viską padarys per pusdienį ir ateis prašyti apsunkinti užduotį. Praktiškai mes vos spėjome atlikti pagrindinę užduotį. Mes dirbome su JS ir Python, kurie atspindi dabartinę pramonės būklę.

Čia irgi rezultatų siekė gerai koordinuotos komandos, kuriose buvo kuriamas darbo pasidalijimas, buvo aišku, kas ką daro.

Trečioji komanda „FSociety“ lyg ir turėjo sprendimą, bet galiausiai nusprendė nerodyti savo tobulėjimo, pasakė, kad nemano, kad tai pasiteisintų. Mes tai gerbiame ir nesiginčijome.

Nugalėtoja tapo „Strippers from Baku“ komanda, kuri sugebėjo save sustabdyti, ne vaikytis „niekučių“, o sukurti MVP, kurį nesigėdija rodyti ir kuris aišku, kad jį galima tobulinti ir didinti. Iš karto jiems pasakėme, kad papildomomis galimybėmis nesame per daug suinteresuoti. Jei jie nori registruotis naudodami QR kodą, veido atpažinimą, leiskite jiems pirmiausia programoje sudaryti grafikus, o tada pasirinkti neprivalomus.

Šioje trasoje „Wet Hair“ užtikrintai pateko į finalą, su jais ir „Hustlers“ aptarėme tolesnį bendradarbiavimą. Su pastaruoju jau susitikome naujaisiais metais.

Tikiuosi, kad viskas pavyks, ir laukiame visų antrajame hakatone kovo mėnesį!

Šaltinis: www.habr.com

Добавить комментарий