Hallo, Habr. Ons het spontaan ons eerste interne hackathon gehou. Ek het besluit om my pyne en gevolgtrekkings oor die voorbereiding vir dit oor 2 weke met julle te deel, asook die projekte wat geblyk het te wees.
Die vervelige deel vir diegene wat belangstel in bemarking
Ek begin met 'n klein storie.
Begin April. Die eerste MskDotNet Community hackathon vind in ons kantoor plaas. Die Slag van Tatooine is hierdie keer in volle swang in ons sterrestelsel. Saterdag. 20 spanne. Pizza. Alles is baie opreg (). ’n Opblaasbare R2-D2 dryf in die saal rond. Spanne skryf die mees korrekte algoritmes om die gevaarlikste wedloop op die kaart te slaag. Ons skuif die bekendstelling van die eerste wedrenne. Koekies en koffie is lewensredders. Ek en die organiseerders het verwag dat baie mense Saterdag na middagete sou vertrek. Maar nee. 12 uur se kodering agter. Die finaal. Iets val af, iets begin nie. Maar almal is gelukkig. Ons span wen. Ons is dubbel gelukkig.
Ek deel my vreugde in Slack en die idee kom by my op: "Ons moet ons eie hackathon doen." Ek skryf aan ons diensstasie Sasha. Stilte.
Oggend. Ek drink koffie in die kantoor. Ek sien Sasha van agter af naderkom. “Lisa, dit is wonderlik! Ons het 'n belangrike datum op 21 April. Kom ons doen dit!" WTF!? So vinnig? A? Wat? Ek moet middel April na Syktyvkar vlieg vir 'n internskap. En te hel daarmee! Kom ons.
2 weke oor. Ek was nog nooit die enigste organiseerder van 'n hackathon nie. Laat dit intern wees. Ek lees artikels oor hierdie onderwerp. Moeilik. Dit neem etlike maande. Verskeie mense word benodig. Jy moet dink oor goedere, pryse, voorwaardes, skedule, rente, die doelwit, begrotings verstaan. Of dalk selfs die sin van die lewe uitvind. Ek sal dit beslis nie betyds maak nie. En terwyl jy besig was om te lees en voor te berei, het 'n week reeds verbygegaan. Dit is tyd om van die artikels te vergeet en iets te begin doen.
Kry ons kontrolelys vir die hou van 'n interne hackathon in 1 week
- plan: Jy gaan sit rustig en skryf 'n lys van wat gedoen moet word vir die hackathon. 30 minute.
- Taak: Deelnemers stel voor en kies die projekte wat hulle in Google Sheets wil skep. Agtergrondtaak, 2 uur.
- Rooster: op jou knie skryf jy 'n kort uiteensetting van tyd, met inagneming van 3 pouses en die finaal. 20 minute.
- Команды: publiseer 'n boodskap oor die hackathon met 'n skedule vanaf die diensstasie in IT-kanale in Slack/mail/ens en skep 'n aparte kanaal vir die hackathon. Daarin word almal in spanne verdeel, en diegene wat onseker is, doen dit in die eerste 5 minute van die hackathon. Agtergrondtaak, 2 uur.
- Broodjies: jy kom met handelsware met twee ontwikkelaars, gee dit aan die ontwerper vir lewering, en ontvang dit gereed. Agtergrondtaak, 3 dae.
- Hackathon: jy kom kantoor toe, koördineer almal aan die begin, gaan oor jou besigheid, lees Reddit, kondig belangrik elke pouse oor vars pizza aan, neem foto's van die sonsondergang, kondig die finaal aan, stem saam en kies die wenner. 1 dag.
- Onder die asterisk: Natuurlik dink jy gedurig daaraan dat alles goed gaan. Natuurlik sal nie almal jou boodskap sien nie en dit is beter om persoonlik met sommige te praat. Natuurlik, as iemand jou help, sal alles 2 keer makliker word (die wonderlike Alena het my gehelp).
Die minder vervelige deel oor die hackathon-datum
Hoekom 21 April? Hierdie dag is vir ons betekenisvol. Presies 'n jaar gelede, op 21 April, het ons gedurende die eerste naweek ná die begin van die Federale Advertensieveldtog onder beurt geval. Die volgende dag, Sondag, was ons span vanaf 8:12 by die werk. Toe het ons 'n sondaghackathon-bord in Trello geskep en 'n week van skofwerk het begin, XNUMX uur per dag. Die situasie was so kritiek dat ons nie eers tyd gehad het om te eet nie en ons is gevoed deur ouens van ander spanne.
Jy kan 'n meer gedetailleerde storie lees by (ons HUB). Sedertdien het ons baie verander, maar nou sal ons beslis nie die datum vergeet nie.
Hierdie jaar het ons besluit dat hierdie geleentheid die moeite werd is om voort te sit in die nagedagtenis en, in die beste tradisies, het ons die eerste interne hackathon in die Dodo-geskiedenis gereël, wat 10 uur geduur het.
Die verveligste deel van hackathon-projekte
Disclaimer: al die beskrywings is deur die ouens self geskryf, so die outeurskap van die teks is nie myne nie.
Oleg Learning (masjienleer)
Dima Kochnev, Sasha Andronov (@alexandronov)
Hulle wou 'n neurale netwerk maak wat sou bepaal watter soort pizza op 'n foto is sonder enige kennis. As gevolg hiervan het ons 'n baie eenvoudige en speelgoed een gemaak - dit herken 10 pizzas, ons het min of meer uitgepluis hoe alles werk, so ver as moontlik in 'n dag (~ 10 uur).
Ons het veral besef dat die bedryf 'n vlak bereik het waar 'n gewone ontwikkelaar klaargemaakte biblioteke kan neem, die dokumentasie kan lees en sy neurale netwerk kan oplei sonder diepgaande kennis van die onderwerp. En dit sal goed genoeg werk om werklike probleme op te los.
Gereedskap wat gebruik word:
- - 'n gerieflike en eenvoudige biblioteek om met masjienleer en rekenaarvisie te werk.
- Ons het twee modelle probeer - ResNet50, Yolo.
- Die kode is natuurlik in Python geskryf.
Ons het 11000 3 foto's gehad, maar amper 4/500 van hulle het geblyk rommel te wees, en die res het verskillende, onvanpaste hoeke gehad. As gevolg hiervan het ons 'n klaargemaakte model geneem (wat eenvoudig weet hoe om pizza te vind) en met sy hulp het ons die asblik geskei. Vervolgens het die titel van die foto die naam van die pizza ingesluit - so ons het dit in dopgehou gesorteer, maar dit het geblyk dat die name nie met die werklikheid saamgeval het nie en ons moes dit met ons hande skoonmaak. Op die ou end was daar so 600-10 foto's oor, dit is duidelik dat dit 'n onbeduidende hoeveelheid is, maar dit was nietemin genoeg om XNUMX pizzas van mekaar te skei.
Om die rooster op te lei, het ons die goedkoopste virtuele masjien in Azure op 'n NVIDIA Tesla K80 geneem. Hulle het vir 100 tydperke daarop opgelei, maar dit was duidelik dat die netwerk ná 50 tydperke oorversadig was, as gevolg van die feit dat daar 'n klein datastel was.
Eintlik is die hele probleem die gebrek aan goeie data.
Ons het die terme dalk 'n bietjie verwar, maar ons moet in ag neem dat ons glad nie ondervinding het om met al hierdie sake te werk nie.
GUI vir NOOBS (konsole om pizza te bestel)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
Ons het 'n prototipe van 'n konsole-toepassing vir geeks saamgestel, waardeur u pizza deur die terminaal of opdragreël kan bestel, of dit selfs in die ontplooiingspyplyn kan integreer en, na suksesvolle vrystelling, pizza by die kantoor kan aflewer.
Die werk is in verskeie dele verdeel: ons het uitgepluis hoe ons API vir mobiele toepassings werk, ons eie CLI saamgestel met en die publikasie van die pakket wat ons ingesamel het, gekonfigureer. Die laaste taak het 'n paar onaangename minute na die einde van die hackathon behels. Alles het plaaslik vir ons gewerk, en selfs die ou gepubliseerde weergawes van die pakket het gewerk, maar die nuwes (wat meer cool kenmerke en emoticons bygevoeg het) het geweier om te werk. Ons het ongeveer 40 minute spandeer om te probeer uitvind wat verkeerd geloop het, maar uiteindelik het alles op sy eie gewerk).
Ons maksimum program vir die hackathon was 'n ware bestelling van pizza na die kantoor deur ons CLI. Ons het alles 'n dosyn keer op die toetsbank gehardloop, maar my hande het steeds gebewe toe ek bevele in produksie ingevoer het.
Gevolglik het ons dit uiteindelik gedoen!
CourierGo
Anton Bruzhmelev (skrywer), Vanya Zverev, Gleb Lesnikov (), Andrey Sarafanov
Ons het die idee van 'n "App vir Koerier" geneem.
Agtergrond oor voorbereiding.Aanvanklik het ek gewonder watter soort kenmerke in die toepassing kan wees? Die volgende lys funksies het na vore gekom:
- Die toepassing meld aan by die afleweringskasregister met die kode.
- Die toepassing wys onmiddellik beskikbare bestellings en bestellings wat geneem moet word.
- Die koerier teken die bestelling aan en neem dit op die reis.
- Hy word die geskatte tyd gewys en of hy betyds is of nie.
- Wys die kliënt dat die koerier vertrek het.
- Die kliënt begin om die koerier se punt op die kaart en die geskatte tyd gewys te word.
- Die koerier kan in die klets vanaf die toepassing aan die kliënt skryf.
- Die kliënt kan via klets vanaf die toepassing aan die koerier skryf.
- Vyf minute voor aankoms kry die kliënt 'n boodskap dat die koerier naby is, wees voorbereid.
- Die koerier merk in die aansoek aan dat hy opgedaag het en wag.
- Die koerier bel met een kliek vanaf die toepassing en rapporteer dat (opkom, het aangekom, ens.)
- Die kliënt aanvaar die bestelling en voer 'n PIN-kode vanaf die toepassing of SMS in om aflewering te bevestig.(as 'n handtekening) Sodat die koerier nie die aflewering vooraf kan voltooi as hy laat is nie.
- Die bestelling word gemerk as afgelewer in die stelsel.
Plus 'n paar alternatiewe scenario's:
- Die koerier kan die bestelling as onafgelewer merk en die rede kies.
- As jy laat is, kan die koerier ’n elektroniese sertifikaat per SMS met een knoppie uitreik. Of die sertifikaat kom outomaties as die afleweringsperdatum nie nagekom word nie.
Die gevoel van belofte en noodsaaklikheid van hierdie projek was natuurlik energiek.
Die volgende dag het ons saam met die span middagete gaan eet en bespreek hoe die minimum funksionaliteit van die toepassing sal lyk.
Gevolglik is die volgende lys gevorm van wat by die hackathon gedoen moes word:
- Teken in by die afleweringskasregister.
- Vertoon huidige posisie.
- Stuur data na 'n eksterne API (koördinate, het die bestelling ontvang, die bestelling afgelewer).
- Ontvang data van eksterne API (huidige koerierbestellings).
- Stuur 'n geleentheid wat aandui dat jy die bestelling geneem het vir aflewering/afgelewer.
- Vertoon die huidige posisie van die koerier op die kaart op die webwerf.
Die hoofwerk, soos dit gelyk het, lê in die skep van die agterkant, die toepassing self (na besprekings het ons ReactNative gekies om die toepassing te ontwikkel, of eerder die raamwerk daarvoor - , wat jou toelaat om glad nie inheemse kode te skryf nie). Wat die backend betref, was daar aanvanklik hoop in Vanya Zverev, aangesien hy ervare was in die werk met ons dienssjabloon en k8's (watter pos hy opgeneem het). Ek en Andrey Sarafanov het ReactNative vir 'n draai geneem.
Ek het besluit om dadelik 'n werkende bewaarplek vir die projek self te probeer skep. Om 12 in die nag het ek afgekom op die feit dat geolocation in die agtergrond nie goed werk in ReactNative nie, as jy nie inheemse kode skryf nie, was ek 'n bietjie gefrustreerd. Toe laat ek gaan toe ek besef dat ek die dokumentasie nie van die expo.io-raamwerk lees nie, maar van ReactNative. Gevolglik het ek in die loop van die aand reeds verstaan hoe om die huidige posisie in expo.io te kry en aparte skerms te teken (vir aanmelding, bestelling vertoon, ens.).
Die oggend by die hackathon het hulle Gleb in hul superbelowende projek gelok. Hulle het vinnig met 'n plan vorendag gekom van wat gedoen moet word.
Ons het 'n fout gemaak toe ons, in ooreenstemming met die projeksjabloon, probeer het om nie via HTTP nie, maar via GRPC te kommunikeer, aangesien niemand geweet het hoe om 'n GRPC-kliënt vir JavaScript te bou nie. Op die ou end, nadat ons ongeveer 'n uur en 'n half hieraan bestee het, het ons hierdie idee laat vaar. As gevolg hiervan het die ouens aan die agterkant begin om die voltooide bediener van GRPC na WebApi te herskep. Na 'n halfuur kon ons uiteindelik kommunikasie tussen die toepassing en die backend opstel, siedaar. Maar terselfdertyd was Gleb amper besig om die ontplooiing na k8s af te rond en plus die outo-ontplooiing van 'n commit aan die meester. 🙂
Ons het MySQL as 'n berging gekies om ten minste nie risiko's te neem met die databasis nie (ons het gedagtes oor CosmosDb gehad).
Ter opsomming:
- Implementeer die stoor van die huidige koördinate van die koerier vanaf die toepassing na die databasis.
- Ons het RabbitMQ geïnstalleer en ingeteken op boodskappe oor die koerier wat 'n bestelling optel om onmiddellik die bestelling van die koerier in die toepassing te vertoon.
- Ons het begin om die bestelling se afleweringstyd in ons databasis te stoor nadat die koerier 'n knoppie in die toepassing gedruk het. Ons het nie tyd gehad om by te voeg om 'n gebeurtenis terug te stuur na die rebbit dat die bestelling afgelewer is nie.
- Ek het 'n kaart vertoon op die huidige bestelling bladsy op die webwerf met die huidige posisie van die koerier. Maar hierdie funksionaliteit het 'n bietjie onvoltooid gebly, aangesien dit nie moontlik was om CORS in die omgewing op te stel om koördinate van ons nuwe diens te ontvang nie.
M87
Roma Bukin, Gosha Polevoy (), Artyom Trofimushkin
Ons wou 'n OpenID Connect-verskaffer implementeer, aangesien ons tans 'n verifikasieprotokol van ons eie ontwerp gebruik, en dit skep 'n aantal probleme: pasgemaakte kliëntbiblioteke, ongerieflike werk aan die kant van eksterne vennote, moontlike sekuriteitsprobleme (na alles) , OAuth2.0 en OpenID Connect in die verwysingsimplementering kan as veilig beskou word, maar ek is nie seker oor ons oplossing nie).
Ons het 'n aparte diens gemaak wat 'n diens vir die berging van persoonlike data naboots om 'n klein land-agnostiese model van 'n stawingverskaffer te skep wat na 'n aparte diens vir persoonlike data sou gaan (dit sal dit in die toekoms moontlik maak om een diens met wat 'n mens kan aanmeld met 'n rekeningregistrasie in enige land, en terselfdertyd aan GDPR en ander federale wette voldoen). Ons het hierdie deel gedoen, net soos die verskaffer, en hulle suksesvol met mekaar verbind. Vervolgens was dit nodig om 'n API te skep wat beskerm sou word deur tekens wat deur die verskaffer uitgereik is, hul introspeksie deur die verskaffer ondersteun en beskermde data terugstuur as die versoek aan die magtigingsbeleide voldoen (ons kontroleer dat die gebruiker geverifieer is volgens die Draerskema , sy teken bevat 'n sekere omvang + y Die gebruiker self het 'n toestemming wat toelaat dat die oproep gemaak word). Hierdie deel is ook voltooi. Die laaste komponent was 'n JavaScript-kliënt, wat 'n teken gegee sou word, met behulp waarvan dit 'n beskermde API sou noem. Ons het nie tyd gehad om hierdie deel te doen nie. Dit wil sê, die hele funksionele deel was gereed, maar die front-end deel was nie gereed om die funksionaliteit van die hele stelsel te demonstreer nie.
E-E-E (speelgoed)
Dima Afonchenko, Sasha Konovalov
Ons het 'n mini-speelding op yunka gemaak waar ywerige hande wors op pizza gooi. As jy die wors verkeerd opsit, verskyn 'n hartseer "Rejected"-boodskap op die skerm, en as al die wors reg opgesit is, verskyn 'n lukrake feit oor pizza.
Ons wou 'n tweede vlak maak met tamaties gooi, maar ons het nie tyd gehad nie.
Kort vervolg: wie het gewen?
Voor die hackathon het ons met die ouens gesels en ek het gevra watter prys hulle graag sou wou ontvang as hulle wen. Dit het geblyk dat die waardevolste prys “die pad na kos” sou wees.
Verwag daarom dat ons binnekort 'n speletjie met hande sal aankondig wat pepers op pizza sit.
Soos 'n oplettende leser dalk opgemerk het, het die span "E-E-E (speelgoed)" gewen. Baie geluk ouens!
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Van watter projek het jy die beste gehou?
-
Oleg Learning (masjienleer)
-
GUI vir NOOBS
-
CourierGo
-
M87
-
E-E-E
5 gebruikers het gestem. 3 gebruikers het buite stemming gebly.
Bron: will.com