Hola, Habr. Vam celebrar espontàniament el nostre primer hackathon intern. Vaig decidir compartir amb vosaltres els meus dolors i conclusions sobre la preparació per a això en 2 setmanes, així com els projectes que van resultar ser.
La part avorrida per als interessats en el màrqueting
Començaré amb una petita història.
Principis d'abril. El primer hackathon de la comunitat MskDotNet està tenint lloc a la nostra oficina. La batalla de Tatooine està en ple apogeu a la nostra galàxia aquesta vegada. dissabte. 20 equips. Pizza. Tot és molt sincer (). Un inflable R2-D2 flota per la sala. Els equips escriuen els algorismes més correctes per superar la carrera més perillosa del mapa. Seguim el llançament de les primeres curses. Les galetes i el cafè són salvavides. Els organitzadors i jo esperàvem que dissabte se n'anés molta gent després de dinar. Però no. 12 hores de codificació enrere. El final. Alguna cosa cau, alguna cosa no comença. Però tothom està content. El nostre equip guanya. Estem doblement feliços.
Comparteixo la meva alegria a Slack i em ve al cap la idea: "Hem de fer el nostre propi hackathon". Escric a la nostra estació de servei Sasha. Silenci.
Al matí. Bec cafè a l'oficina. Veig que la Sasha s'acosta per darrere. "Lisa, això és genial! Tenim una cita important el 21 d'abril. Fem-ho!" WTF!? Molt ràpid? A? Què? Necessito volar a Syktyvkar per fer pràctiques a mitjans d'abril. I a la merda! Anem.
Queden 2 setmanes. Mai he estat l'únic organitzador d'un hackató. Que sigui intern. He llegit articles sobre aquest tema. Dur. Es triga uns quants mesos. Es necessiten diverses persones. Heu de pensar en la mercaderia, els premis, les condicions, l'horari, l'interès, entendre l'objectiu, els pressupostos. O potser fins i tot esbrinar el sentit de la vida. Definitivament no arribaré a temps. I mentre estaves llegint i preparant, ja havia passat una setmana. És hora d'oblidar-se dels articles i començar a fer alguna cosa.
Consulta la nostra llista de comprovació per celebrar un hackathon intern en 1 setmana
- Pla: Seieu tranquil·lament i escriviu una llista del que cal fer per al hackathon. Minuts 30.
- Tasca: Els participants proposen i trien els projectes que volen crear a Google Sheets. Tasca de fons, 2 hores.
- Horaris: al teu genoll escriviu un breu desglossament del temps, tenint en compte 3 descansos i el final. Minuts 20.
- Equips: publiqueu un missatge sobre el hackathon amb una programació de l'estació de servei als canals informàtics a Slack/mail/etc i creeu un canal separat per al hackathon. En ell, tothom es divideix en equips, i els indecisos ho fan en els primers 5 minuts del hackathon. Tasca de fons, 2 hores.
- Bollos: us presenteu la mercaderia amb dos desenvolupadors, la doneu al dissenyador perquè la representi i la rebeu a punt. Tasca de fons, 3 dies.
- Hackathon: veneu a l'oficina, coordineu tothom al principi, feu el vostre negoci, llegiu Reddit, anuncieu cada pausa sobre pizza fresca, feu fotos de la posta de sol, anuncieu la final, voteu junts i trieu el guanyador. Dia 1.
- Sota l'asterisc: Per descomptat, penses constantment que tot va bé. Per descomptat, no tothom veurà el teu missatge i és millor parlar amb algú en persona. Per descomptat, si algú t'ajuda, tot serà 2 vegades més fàcil (la meravellosa Alena em va ajudar).
La part menys avorrida de la cita del hackathon
Per què el 21 d'abril? Aquest dia és important per a nosaltres. Fa exactament un any, el 21 d'abril, vam caure sota càrrega durant el primer cap de setmana després de l'inici de la Campanya Federal de Publicitat. L'endemà, diumenge, el nostre equip estava treballant a partir de les 8 del matí. Després vam crear un tauler de sundayhackathon a Trello i va començar una setmana de treball per torns, 12 hores al dia. La situació era tan crítica que ni tan sols vam tenir temps per menjar i ens van alimentar nois d'altres equips.
Podeu llegir una història més detallada a (el nostre CEO). Des de llavors, hem canviat molt, però ara segur que no oblidarem la data.
Enguany vam decidir que aquest esdeveniment valia la pena perpetuar-se en la memòria de la posteritat i, amb la millor tradició, vam organitzar el primer hackathon intern de la història de Dodo, que va durar 10 hores.
La part més avorrida dels projectes hackathon
Exempció de responsabilitat: totes les descripcions van ser escrites pels mateixos nois, de manera que l'autoria del text no és meva.
Oleg Learning (aprenentatge automàtic)
Dima Kochnev, Sasha Andronov (@alexandronov)
Volien fer una xarxa neuronal que determinés quin tipus de pizza hi ha en una foto sense cap coneixement. Com a resultat, n'hem fet una de molt senzilla i de joguina: reconeix 10 pizzes, aproximadament hem descobert com funciona tot, en la mesura del possible en un dia (~10 hores).
En particular, ens vam adonar que la indústria ha assolit un nivell en què un desenvolupador normal pot agafar biblioteques ja fetes, llegir la documentació i entrenar la seva xarxa neuronal sense un coneixement profund del tema. I funcionarà prou bé per resoldre problemes reals.
Eines utilitzades:
- — una biblioteca còmoda i senzilla per treballar amb aprenentatge automàtic i visió per ordinador.
- Hem provat dos models: ResNet50, Yolo.
- El codi es va escriure, per descomptat, en Python.
Vam tenir 11000 fotos, però gairebé 3/4 d'elles van resultar ser escombraries, i la resta tenien angles diferents i inadequats. Com a resultat, vam agafar una maqueta ja feta (que simplement sap trobar pizza) i amb la seva ajuda vam separar les escombraries. A continuació, el títol de la foto incloïa el nom de la pizza, així que la vam ordenar en carpetes, però va resultar que els noms no coincidien amb la realitat i vam haver de netejar-la manualment. Al final, quedaven unes 500-600 fotos, és clar que es tracta d'una quantitat insignificant, però, tanmateix, això va ser suficient per separar 10 pizzes les unes de les altres.
Per entrenar la graella, vam agafar la màquina virtual més barata d'Azure en una NVIDIA Tesla K80. S'hi van entrenar durant 100 èpoques, però era evident que la xarxa estava sobresaturada després de 50 èpoques, a causa del fet que hi havia un petit conjunt de dades.
De fet, tot el problema és la manca de bones dades.
Potser hem confós una mica els termes, però hem de tenir en compte que no tenim cap experiència en treballar amb tots aquests temes.
GUI per a NOOBS (consola per demanar pizza)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
Hem creat un prototip d'aplicació de consola per a geeks, gràcies a la qual podeu demanar pizza a través del terminal o la línia d'ordres, o fins i tot integrar-la al pipeline de desplegament i, un cop s'ha llançat amb èxit, lliurar pizza a l'oficina.
El treball es va dividir en diverses parts: vam descobrir com funciona la nostra API per a aplicacions mòbils, vam muntar la nostra pròpia CLI mitjançant i hem configurat la publicació del paquet que hem recollit. L'última tasca va implicar uns minuts desagradables cap al final del hackathon. Tot funcionava localment per a nosaltres, i fins i tot les antigues versions publicades del paquet van funcionar, però les noves (que van afegir funcions i emoticones més interessants) es van negar a funcionar. Vam passar uns 40 minuts intentant esbrinar què va fallar, però al final tot va funcionar màgicament per si sol).
El nostre programa màxim per al hackathon va ser una comanda real de pizza a l'oficina a través del nostre CLI. Ho vam executar tot una dotzena de vegades al banc de proves, però encara em tremolaven les mans quan vaig introduir ordres en producció.
Com a resultat, finalment ho hem aconseguit!
CourierGo
Anton Bruzhmelev (autor), Vanya Zverev, Gleb Lesnikov (), Andrei Sarafanov
Vam agafar la idea d'una "aplicació per a missatgeria".
Antecedents sobre la preparació.Inicialment, em vaig preguntar quin tipus de funcions podrien tenir l'aplicació? Va sorgir la següent llista de funcionalitats:
- L'aplicació inicia sessió a la caixa registradora de lliurament mitjançant el codi.
- L'aplicació mostra immediatament les comandes disponibles i les comandes que cal prendre.
- El missatger anota la comanda i la porta al viatge.
- Se li mostra el temps estimat i si arriba a temps o no.
- Mostra al client que el missatger ha marxat.
- Al client li comença a mostrar el punt del missatger al mapa i el temps estimat.
- El missatger pot escriure al client al xat des de l'aplicació.
- El client pot escriure al missatger via xat des de l'aplicació.
- Cinc minuts abans de l'arribada, el client rep un missatge que el missatger està a prop, estigueu preparats.
- El missatger assenyala a la sol·licitud que ha arribat i està esperant.
- El missatger truca des de l'aplicació amb un sol clic i informa que (està pujant, ha arribat, etc.)
- El client accepta la comanda i introdueix un codi PIN des de l'aplicació o SMS per confirmar l'entrega (com a signatura) Per tal que el missatger no pugui completar l'entrega amb antelació si arriba tard.
- La comanda està marcada com a lliurada al sistema.
A més d'un parell d'escenaris alternatius:
- El missatger pot marcar la comanda com a no lliurada i seleccionar el motiu.
- En cas de retard, el missatger pot emetre un certificat electrònic per SMS amb un sol botó. O el certificat arriba automàticament si no es compleix el termini de lliurament.
La sensació de promesa i necessitat d'aquest projecte va ser, per descomptat, energitzant.
L'endemà vam anar a dinar amb l'equip i vam comentar com seria la funcionalitat mínima de l'aplicació.
Com a resultat, es va formar la següent llista del que s'havia de fer a l'hackathon:
- Inicieu sessió a la caixa registradora de lliurament.
- Mostra la posició actual.
- Enviar dades a una API externa (coordenades, rebre la comanda, lliurar la comanda).
- Rebre dades de l'API externa (comandes de missatgeria actuals).
- Envieu un esdeveniment indicant que heu pres la comanda per al lliurament/entrega.
- Mostra la posició actual del missatger al mapa del lloc web.
El treball principal, segons semblava, consistia en crear el backend, l'aplicació en si (després de les discussions, vam triar ReactNative per desenvolupar l'aplicació, o més aviat el marc per a ella - , que us permet no escriure codi natiu en absolut). Pel que fa al backend, inicialment hi havia esperança en Vanya Zverev, ja que tenia experiència treballant amb la nostra plantilla de servei i els k8s (la feina que va assumir). Andrey Sarafanov i jo vam fer una volta a ReactNative.
Vaig decidir intentar crear immediatament un repositori de treball per al projecte en si. A les 12 de la nit em vaig trobar amb el fet que la geolocalització en segon pla no funciona bé a ReactNative, si no escrius codi natiu, em va frustrar una mica. Llavors vaig deixar anar quan em vaig adonar que estava llegint la documentació no del marc expo.io, sinó de ReactNative. Com a resultat, al llarg de la nit ja vaig entendre com obtenir la posició actual a expo.io i dibuixar pantalles separades (per iniciar sessió, mostrar comandes, etc.).
Al matí a l'hackathon, van atraure Gleb al seu projecte súper prometedor. Ràpidament van elaborar un pla del que calia fer.
Ens vam equivocar quan, d'acord amb la plantilla del projecte, vam intentar comunicar-nos no per HTTP, sinó per GRPC, ja que ningú sabia com construir un client GRPC per a JavaScript. Al final, després de dedicar-hi aproximadament una hora i mitja, vam abandonar aquesta idea. Per això, els nois del back-end van començar a refer el servidor acabat de GRPC a WebApi. Després de mitja hora, finalment vam poder establir la comunicació entre l'aplicació i el backend, he aquí. Però al mateix temps, Gleb gairebé estava acabant el desplegament a k8s i, a més, el desplegament automàtic d'un commit al mestre. 🙂
Hem escollit MySQL com a emmagatzematge per no córrer riscos almenys amb la base de dades (teníem pensaments sobre CosmosDb).
En resum:
- Implementat guardant les coordenades actuals del missatger de l'aplicació a la base de dades.
- Hem instal·lat RabbitMQ i ens vam subscriure als missatges sobre el missatger que va recollir una comanda per mostrar immediatament la comanda del missatger a l'aplicació.
- Vam començar a estalviar el temps de lliurament de la comanda a la nostra base de dades després que el missatger prement un botó de l'aplicació. No hem tingut temps d'afegir l'enviament d'un esdeveniment al rebbit que es va lliurar la comanda.
- Vaig fer una visualització de mapa a la pàgina de comanda actual del lloc web amb la posició actual del missatger. Però aquesta funcionalitat va quedar una mica inacabada, ja que no era possible configurar CORS a l'entorn per rebre coordenades del nostre nou servei.
M87
Roma Bukin, Gosha Polevoy (), Artyom Trofimushkin
Volíem implementar un proveïdor d'OpenID Connect, ja que de moment utilitzem un protocol d'autenticació de disseny propi, i això crea una sèrie de dificultats: biblioteques de clients personalitzades, treball incòmode per part de socis externs, possibles problemes de seguretat (al cap i a la fi. , OAuth2.0 i OpenID Connect a la implementació de referència es poden considerar segurs, però no estic segur de la nostra solució).
Vam crear un servei independent que emulava un servei per emmagatzemar dades personals per tal de crear un petit model d'un proveïdor d'autenticació independent del país que aniria a un servei independent de dades personals (això permetria en el futur tenir un servei amb que es podria iniciar sessió amb un registre de compte a qualsevol país i, al mateix temps, complir amb el GDPR i altres lleis federals). Vam fer aquesta part, igual que el proveïdor, i els vam enllaçar amb èxit. A continuació, va ser necessari crear una API que estigués protegida per tokens emesos pel proveïdor, donar suport a la seva introspecció a través del proveïdor i retornar les dades protegides si la sol·licitud complia les polítiques d'autorització (comprovem que l'usuari estigui autenticat segons l'esquema Bearer). , el seu testimoni conté un cert abast + y El propi usuari té un permís que permet fer la trucada). Aquesta part també es va completar. L'últim component era un client JavaScript, al qual se li donaria un testimoni, amb l'ajuda del qual anomenaria una API protegida. No hem tingut temps de fer aquesta part. És a dir, tota la part funcional estava preparada, però la part frontal no estava preparada per demostrar la funcionalitat de tot el sistema.
E-E-E (joguina)
Dima Afonchenko, Sasha Konovalov
Vam fer una minijoguina a la yunka on les mans juguetones llencen botifarra a la pizza. Si poseu la botifarra de manera incorrecta, apareix un trist missatge "Rebutjat" a la pantalla i, si tota la botifarra s'ha posat correctament, apareix un fet aleatori sobre la pizza.
Volíem fer un segon nivell amb tirar tomàquets, però no vam tenir temps.
Breu continuació: qui va guanyar?
Abans del hackathon, vam parlar amb els nois i els vaig preguntar quin premi els agradaria rebre si guanyaven. Va resultar que el premi més valuós seria "el camí cap al menjar".
Per tant, espereu que aviat anunciem un joc amb mans que posen pebrots a la pizza.
Com podria haver notat un lector atent, l'equip "E-E-E (joguina)" va guanyar. Felicitats nois!
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Quin projecte t'ha agradat més?
-
Oleg Learning (aprenentatge automàtic)
-
GUI per a NOOBS
-
CourierGo
-
M87
-
E-E-E
Han votat 5 usuaris. 3 usuaris es van abstenir.
Font: www.habr.com