Bună, Habr. Am organizat spontan primul nostru hackathon intern. Am decis să vă împărtășesc durerile și concluziile mele despre pregătirea pentru ea în 2 săptămâni, precum și proiectele care s-au dovedit a fi.
Partea plictisitoare pentru cei interesați de marketing
Voi începe cu o mică poveste.
Începutul lunii aprilie. Primul hackathon al comunității MskDotNet are loc în biroul nostru. Bătălia de la Tatooine este în plină desfășurare în galaxia noastră de data aceasta. Sâmbătă. 20 de echipe. Pizza. Totul este foarte sincer (). Un R2-D2 gonflabil plutește în jurul holului. Echipele scriu cei mai corecti algoritmi pentru a trece cea mai periculoasă cursă de pe hartă. Mutăm lansarea primelor curse. Biscuiții și cafeaua sunt salvatoare. Organizatorii și cu mine ne așteptam ca mulți oameni să plece după prânz sâmbătă. Dar nu. 12 ore de codare în urmă. Finala. Ceva cade, ceva nu începe. Dar toată lumea este fericită. Echipa noastră câștigă. Suntem de două ori fericiți.
Îmi împărtășesc bucuria în Slack și îmi vine în minte ideea: „Trebuie să facem propriul nostru hackathon”. Vă scriu la stația noastră de service Sasha. Tăcere.
Dimineaţă. Eu beau cafea la birou. O văd pe Sasha apropiindu-se din spate. „Lisa, asta e grozav! Avem o dată importantă pe 21 aprilie. Hai să o facem!" WTF!? Atat de rapid? A? Ce? Trebuie să zbor la Syktyvkar pentru un stagiu la mijlocul lunii aprilie. Și la naiba cu asta! hai sa.
Au mai rămas 2 săptămâni. Nu am fost niciodată singurul organizator al unui hackathon. Să fie intern. Am citit articole pe acest subiect. Greu. Durează câteva luni. Este nevoie de mai multe persoane. Trebuie să vă gândiți la marfă, premii, condiții, program, interes, înțelegeți obiectivul, bugete. Sau poate chiar să-ți dai seama de sensul vieții. Cu siguranță nu voi ajunge la timp. Și în timp ce citeai și te pregăteai, trecuse deja o săptămână. E timpul să uiți de articole și să începem să faci ceva.
Urmăriți lista noastră de verificare pentru organizarea unui hackathon intern într-o săptămână
- plan: Te așezi calm și scrii o listă cu ceea ce trebuie făcut pentru hackathon. 30 minute.
- Sarcină: Participanții propun și aleg proiectele pe care doresc să le creeze în Foi de calcul Google. Sarcină de fundal, 2 ore.
- Orar: in genunchi scrieti o scurta defalcare a timpului, tinand cont de 3 pauze si de finala. 20 minute.
- comenzi: publicați un mesaj despre hackathon cu un program de la stația de service în canalele IT în Slack/mail/etc și creați un canal separat pentru hackathon. În ea, toată lumea este împărțită în echipe, iar cei indeciși fac acest lucru în primele 5 minute ale hackatonului. Sarcină de fundal, 2 ore.
- chifle: veniți cu produse cu doi dezvoltatori, îl oferiți designerului pentru randare și îl primiți gata. Sarcină de fundal, 3 zile.
- Hackathon: vii la birou, coordonezi pe toți la început, te ocupi de treburile tale, citești Reddit, este important să anunți fiecare pauză despre pizza proaspătă, să faci poze cu apusul, să anunți finala, să votezi împreună și să alegi câștigătorul. 1 zi.
- Sub asterisc: Desigur, te gândești constant că totul merge bine. Desigur, nu toată lumea vă va vedea mesajul și este mai bine să discutați personal cu unii. Desigur, dacă te ajută cineva, totul va deveni de 2 ori mai ușor (m-a ajutat minunata Alena).
Partea mai puțin plictisitoare despre data hackatonului
De ce 21 aprilie? Această zi este semnificativă pentru noi. În urmă cu exact un an, pe 21 aprilie, am căzut sub sarcină în primul weekend de după începerea Campaniei Federale de Publicitate. A doua zi, duminica, echipa noastra era la lucru de la 8 dimineata. Apoi am creat o tablă de Sundayhackathon în Trello și a început o săptămână de lucru în ture, 12 ore pe zi. Situația era atât de critică încât nici nu am avut timp să mâncăm și am fost hrăniți de băieți din alte echipe.
Puteți citi o poveste mai detaliată la (CEO-ul nostru). De atunci, ne-am schimbat foarte mult, dar acum sigur nu vom uita data.
Anul acesta, am decis că acest eveniment merită perpetuat în memoria posterității și, în cele mai bune tradiții, am organizat primul hackathon intern din istoria Dodo, care a durat 10 ore.
Partea cea mai plictisitoare despre proiectele hackathon
Disclaimer: toate descrierile au fost scrise chiar de băieți, așa că autorul textului nu este al meu.
Oleg Learning (învățare automată)
Dima Kochnev, Sasha Andronov (@alexandronov)
Au vrut să facă o rețea neuronală care să determine ce fel de pizza este într-o fotografie fără nicio cunoștință. Drept urmare, am făcut unul foarte simplu și de jucărie - recunoaște 10 pizza, ne-am dat seama cum funcționează totul, pe cât posibil într-o zi (~10 ore).
În special, ne-am dat seama că industria a atins un nivel în care un dezvoltator obișnuit poate lua biblioteci gata făcute, poate citi documentația și își poate antrena rețeaua neuronală fără cunoaștere profundă a subiectului. Și va funcționa suficient de bine pentru a rezolva probleme reale.
Instrumente folosite:
- — o bibliotecă convenabilă și simplă pentru lucrul cu machine learning și computer vision.
- Am încercat două modele - ResNet50, Yolo.
- Codul a fost scris, desigur, în Python.
Am avut 11000 de fotografii, dar aproape 3/4 dintre ele s-au dovedit a fi gunoi, iar restul aveau unghiuri diferite, nepotrivite. Drept urmare, am luat un model gata făcut (care pur și simplu știe să găsească pizza) și cu ajutorul lui am separat gunoiul. În continuare, titlul fotografiei includea numele pizza - așa că am sortat-o în dosare, dar s-a dovedit că numele nu coincid cu realitatea și a trebuit să o curățăm manual. Până la urmă, au rămas aproximativ 500-600 de fotografii, este clar că aceasta este o cantitate nesemnificativă, dar totuși, aceasta a fost suficientă pentru a separa 10 pizza una de alta.
Pentru a antrena grila, am luat cea mai ieftină mașină virtuală din Azure pe un NVIDIA Tesla K80. S-au antrenat pe el timp de 100 de epoci, dar era clar că rețeaua a devenit suprasaturată după 50 de epoci, din cauza faptului că exista un set de date mic.
De fapt, întreaga problemă este lipsa de date bune.
Poate că am confundat puțin termenii, dar trebuie să ținem cont că nu avem deloc experiență în lucrul cu toate aceste chestiuni.
GUI pentru NOOBS (consola pentru comandarea pizza)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
Am creat un prototip de aplicație de consolă pentru geek, datorită căruia puteți comanda pizza prin terminal sau linia de comandă sau chiar o puteți integra în conducta de implementare și, după lansarea cu succes, puteți livra pizza la birou.
Lucrarea a fost împărțită în mai multe părți: ne-am dat seama cum funcționează API-ul nostru pentru aplicațiile mobile, ne-am asamblat propriul CLI folosind și am configurat publicarea pachetului pe care l-am colectat. Ultima sarcină a implicat câteva minute neplăcute spre sfârșitul hackatonului. Totul a funcționat local pentru noi și chiar și versiunile vechi publicate ale pachetului au funcționat, dar cele noi (care au adăugat mai multe caracteristici și emoticoane interesante) au refuzat să funcționeze. Am petrecut aproximativ 40 de minute încercând să ne dăm seama ce a mers prost, dar până la urmă totul a funcționat magic de la sine).
Programul nostru maxim pentru hackathon a fost o comandă reală de pizza la birou prin CLI-ul nostru. Am rulat totul de zeci de ori pe bancul de testare, dar mâinile încă îmi tremurau când am introdus comenzile în producție.
Drept urmare, am reușit în sfârșit!
CourierGo
Anton Bruzhmelev (autor), Vanya Zverev, Gleb Lesnikov (), Andrei Sarafanov
Am luat ideea unei „App for Courier”.
Context despre pregătire.Inițial, m-am întrebat ce fel de caracteristici ar putea fi în aplicație? A apărut următoarea listă de funcționalități:
- Aplicația se conectează în casa de marcat de livrare folosind codul.
- Aplicația arată imediat comenzile disponibile și comenzile care trebuie preluate.
- Curierul notează comanda și o duce în călătorie.
- I se arată timpul estimat și dacă este la timp sau nu.
- Arată clientului că curierul a plecat.
- Clientului începe să i se arate punctul curierului pe hartă și timpul estimat.
- Curierul poate scrie clientului prin chat din aplicație.
- Clientul poate scrie curierului prin chat din aplicație.
- Cu cinci minute înainte de sosire, clientul primește un mesaj că curierul este aproape, fiți pregătiți.
- Curierul notează în aplicație că a sosit și așteaptă.
- Curierul sună din aplicație cu un singur clic și raportează că (crește, a sosit etc.)
- Clientul acceptă comanda și introduce un cod PIN din aplicație sau SMS pentru a confirma livrarea (ca semnătură) Pentru ca curierul să nu poată finaliza livrarea în avans dacă întârzie.
- Comanda este marcată ca livrată în sistem.
Plus câteva scenarii alternative:
- Curierul poate marca comanda ca nelivrată și poate selecta motivul.
- Dacă întârzii, curierul poate emite un certificat electronic prin SMS cu un singur buton. Sau certificatul ajunge automat dacă nu este respectat termenul de livrare.
Sentimentul de promisiune și necesitate al acestui proiect a fost, desigur, energizant.
A doua zi am fost la prânz cu echipa și am discutat cum ar arăta funcționalitatea minimă a aplicației.
Ca urmare, a fost format următoarea listă cu ceea ce trebuia făcut la hackathon:
- Conectați-vă la casa de marcat pentru livrare.
- Afișează poziția curentă.
- Trimiteți date către un API extern (coordonate, primit comanda, livrat comanda).
- Primiți date de la API extern (comenzi curente de curierat).
- Trimiteți un eveniment care să indice că ați preluat comanda pentru livrare/livrare.
- Afișați poziția curentă a curierului pe harta de pe site.
Munca principală, după cum părea, constă în crearea backend-ului, a aplicației în sine (după discuții, am ales ReactNative pentru a dezvolta aplicația, sau mai degrabă cadrul pentru aceasta - , care vă permite să nu scrieți deloc cod nativ). În ceea ce privește backend-ul, inițial a existat speranță în Vanya Zverev, deoarece avea experiență în lucrul cu șablonul nostru de servicii și k8s (pe care a preluat-o slujba). Eu și Andrey Sarafanov am luat ReactNative la o tură.
Am decis să încerc să creez imediat un depozit de lucru pentru proiectul în sine. La 12 noaptea am dat de faptul că geolocalizarea în fundal nu merge bine în ReactNative, dacă nu scrii cod nativ, eram puțin frustrat. Apoi mi-am dat drumul când mi-am dat seama că citeam documentația nu a cadrului expo.io, ci a ReactNative. Drept urmare, de-a lungul serii am înțeles deja cum să obțin poziția curentă în expo.io și să desenez ecrane separate (pentru autentificare, afișare a comenzii etc.).
Dimineața, la hackathon, l-au atras pe Gleb în proiectul lor super promițător. Au venit rapid cu un plan cu ceea ce trebuia făcut.
Am făcut o greșeală când, conform șablonului de proiect, am încercat să comunicăm nu prin HTTP, ci prin GRPC, deoarece nimeni nu știa să construim un client GRPC pentru JavaScript. Până la urmă, după ce am petrecut aproximativ o oră și jumătate pe asta, am abandonat această idee. Din această cauză, băieții de pe back-end au început să refacă serverul terminat de la GRPC la WebApi. După o jumătate de oră, am reușit în sfârșit să stabilim comunicarea între aplicație și backend, iată. Dar, în același timp, Gleb aproape finaliza implementarea pe k8s și, plus, implementarea automată a unui commit către master. 🙂
Am ales MySQL ca stocare ca să nu ne asumăm riscuri măcar cu baza de date (aveam gânduri despre CosmosDb).
În rezumat:
- Implementata salvarea coordonatelor curente ale curierului din aplicatie in baza de date.
- Am instalat RabbitMQ și ne-am abonat la mesaje despre ridicarea unei comenzi de către curier pentru a afișa imediat comanda de la curier în aplicație.
- Am început să salvăm timpul de livrare a comenzii în baza noastră de date după ce curierul a apăsat un buton din aplicație. Nu am avut timp să adăugăm trimiterea unui eveniment înapoi la rebbit că comanda a fost livrată.
- Am realizat o afișare a hărții pe pagina de comandă curentă de pe site cu poziția curentă a curierului. Dar această funcționalitate a rămas puțin neterminată, deoarece nu a fost posibilă configurarea CORS în mediu pentru a primi coordonatele de la noul nostru serviciu.
M87
Roma Bukin, Gosha Polevoy (), Artyom Trofimushkin
Am vrut să implementăm un furnizor OpenID Connect, deoarece în momentul de față folosim un protocol de autentificare de design propriu, iar acest lucru creează o serie de dificultăți: biblioteci client personalizate, lucru incomod din partea partenerilor externi, posibile probleme de securitate (la urma urmei). , OAuth2.0 și OpenID Connect în implementarea de referință pot fi considerate sigure, dar nu sunt sigur de soluția noastră).
Am realizat un serviciu separat care emulează un serviciu de stocare a datelor cu caracter personal pentru a crea un mic model Country-Agnostic al unui furnizor de autentificare care ar merge la un serviciu separat pentru date personale (acest lucru ar face posibilă în viitor un singur serviciu cu care se poate autentifica cu o înregistrare a unui cont în orice țară și, în același timp, se poate respecta GDPR și alte legi federale). Am făcut această parte, la fel ca și furnizorul, și le-am legat cu succes. În continuare, a fost necesar să se creeze un API care să fie protejat de token-uri emise de furnizor, să susțină introspecția acestora prin intermediul furnizorului și să returneze date protejate dacă cererea a îndeplinit politicile de autorizare (verificăm ca utilizatorul să fie autentificat conform schemei Bearer). , jetonul său conține un anumit domeniu + y Utilizatorul însuși are o permisiune care permite efectuarea apelului). A fost finalizată și această parte. Ultima componentă era un client JavaScript, căruia i se acorda un token, cu ajutorul căruia ar apela un API protejat. Nu am avut timp să facem această parte. Adică, întreaga parte funcțională era pregătită, dar partea frontală nu era pregătită pentru a demonstra funcționalitatea întregului sistem.
E-E-E (jucărie)
Dima Afonchenko, Sasha Konovalov
Am făcut o mini-jucărie pe yunka în care mâinile pline de cârnați aruncă cârnați pe pizza. Dacă ați pus cârnații incorect, pe ecran apare un mesaj trist „Respins”, iar dacă tot cârnatul a fost pus corect, apare un fapt întâmplător despre pizza.
Am vrut să facem un al doilea nivel cu aruncarea roșiilor, dar nu am avut timp.
Scurtă continuare: cine a câștigat?
Înainte de hackathon, am vorbit cu băieții și i-am întrebat ce premiu ar dori să primească dacă vor câștiga. S-a dovedit că cel mai valoros premiu ar fi „drumul către mâncare”.
Prin urmare, așteptați-vă să anunțăm în curând un joc cu mâinile care pun ardei pe pizza.
După cum ar fi observat un cititor atent, echipa „E-E-E (jucărie)” a câștigat. Felicitări băieți!
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Care proiect ți-a plăcut cel mai mult?
-
Oleg Learning (învățare automată)
-
GUI pentru NOOBS
-
CourierGo
-
M87
-
E-E-E
Au votat 5 utilizatori. 3 utilizatori s-au abținut.
Sursa: www.habr.com