🥇Codiamo–pizza

Ciao, Habr. Abbiamo tenuto il nostro primo hackathon interno in modo spontaneo. Ho deciso di condividere con voi le mie difficoltà e le conclusioni sulla preparazione, a partire da due settimane fa, oltre ai progetti che sono nati.

La parte noiosa per chi è interessato al marketing

Inizierò con una piccola storia.

Inizio aprile. Nel nostro ufficio si svolge il primo hackathon della MskDotNet Community. La battaglia per Tatooine è in pieno svolgimento, questa volta nella nostra galassia. Sabato. 20 squadre. Pizza. È tutto molto rassicurante (prove). Un R2-D2 gonfiabile si aggira nella sala. I team scrivono gli algoritmi più corretti per affrontare la corsa più pericolosa della mappa. Ritardiamo il lancio delle prime gare. Biscotti e caffè sono un salvataggio. Con gli organizzatori, ci aspettavamo che molte persone se ne andassero dopo pranzo, ma no. 12 ore di codifica alle spalle. Finale. Qualcosa si blocca, qualcosa non si avvia. Ma tutti sono felici. La nostra squadra vince. Siamo felici doppiamente.

Condivido la gioia su Slack e mi viene in mente un'idea: «Dobbiamo fare il nostro hackathon». Scrivo al nostro CTO Sasha. Silenzio.

Mattina. Bevo caffè in ufficio. Vedo Sasha avvicinarsi da dietro. «Liza, è fantastico! Abbiamo una data importante il 21 aprile. Facciamolo!» Cosa?! Così in fretta? Ah? Cosa? Devo volare a Syktyvkar per uno stage a metà aprile. E chi se ne frega! Facciamolo.

Restano due settimane. Non sono mai stata l'unica organizzatrice di un hackathon. Anche se interno. Leggo articoli a riguardo. È un caos. Ci vogliono mesi. Ci vogliono diverse persone. Devo pensare a merchandising, premi, condizioni, programma, coinvolgere le persone, capire l’obiettivo, i budget. Magari anche capire il senso della vita. Non ce la farò. E mentre leggi e ti prepari, è già passata una settimana. È tempo di smettere di leggere articoli e iniziare a fare qualcosa.

Ecco la nostra checklist per organizzare un hackathon interno in una settimana

Piano: ti siedi con calma e scrivi un elenco di ciò che deve essere fatto per l'hackathon. 30 minuti.
Compito: i partecipanti propongono e scelgono i progetti che desiderano creare in Google Sheets. Compito secondario, 2 ore.
Programma: scrivi rapidamente una breve programmazione temporale considerando 3 pause e la finale. 20 minuti.
Team: pubblichi un messaggio riguardante l'hackathon con il programma dal CTO nei canali IT su Slack/email/etc e crei un canale separato per l'hackathon. In esso, tutti si dividono in squadre, e quelli che non hanno ancora deciso lo fanno nei primi 5 minuti dell'hackathon. Compito secondario, 2 ore.
Caratteristiche: crei merchandising con due sviluppatori, lo dai al designer per la realizzazione, ricevi il prodotto finito. Compito secondario, 3 giorni.
Hackathon: arrivi in ufficio, coordini tutti all'inizio, ti occupi delle tue faccende, leggi Reddit, informi con un'aria importante durante ogni pausa riguardo alla pizza fresca, fotografi il tramonto, annunzi il finale, votate insieme e scegliete il vincitore. 1 giorno.
Con un asterisco: certo, pensi sempre a come far sì che tutto vada per il meglio. Naturalmente, non tutti vedranno il tuo messaggio e con alcuni è meglio parlare di persona. Certo, se qualcuno ti aiuta, tutto diventa il doppio più semplice (mi ha aiutata l'ottima Alena).

La parte meno noiosa riguardo alla data dell'hackathon

Perché il 21 aprile? Questa data è significativa per noi. Esattamente un anno fa, il 21 aprile, abbiamo ceduto sotto pressione durante i primi weekend dopo l'inizio della Campagna Pubblicitaria Federale. Il giorno successivo, domenica, la nostra squadra era al lavoro dalle 8 del mattino. Allora abbiamo creato su Trello la bacheca sundayhackathon e ha avuto inizio una settimana di turni di lavoro di 12 ore al giorno. La situazione era così critica che non avevamo nemmeno tempo per mangiare e siamo stati sostenuti dai ragazzi di altri team.

Puoi leggere una storia più dettagliata su pagina di Fëdor Ovkinnikov (il nostro CEO). Da allora, abbiamo cambiato molto, ma ora non dimenticheremo sicuramente questa data.

Quest'anno abbiamo deciso che questo evento meritava di essere ricordato per le generazioni future e, seguendo le migliori tradizioni, abbiamo organizzato il primo hackathon interno della storia di Dodo, della durata di 10 ore.

La parte meno noiosa riguardo ai progetti dell'hackathon

Disclaimer: tutte le descrizioni sono state scritte dai ragazzi, quindi l'autore del testo non sono io.

Oleg Learning (machine learning)

Dima Kocnev, Sasha Andronov (@alexandronov)

Volevamo realizzare una rete neurale in grado di identificare che tipo di pizza c'è in foto senza alcuna conoscenza pregressa. In fin dei conti, abbiamo realizzato qualcosa di molto semplice e giocattoloso: riconosce 10 tipi di pizza, abbiamo più o meno capito come funziona, per quanto sia possibile farlo in un solo giorno (~10 ore).

In particolare, abbiamo capito che l'industria è diventata così accessibile che un normale sviluppatore può prendere librerie pronte, leggere la documentazione e addestrare la propria rete neurale senza conoscenze approfondite. E funzionerà abbastanza bene per risolvere problemi reali.

Strumenti utilizzati:

imageai — una libreria comoda e semplice per lavorare con il machine learning e la visione artificiale.
Abbiamo provato due modelli: ResNet50, Yolo.
Il codice è stato ovviamente scritto in Python.

Avevamo 11000 foto, ma tra di esse quasi 3/4 si sono rivelate spazzatura, mentre nelle rimanenti c'erano angolazioni diverse e inappropriate. Alla fine, abbiamo preso un modello pronto (che semplicemente riesce a trovare la pizza) e con il suo aiuto abbiamo separato la maggior parte delle immagini di scarto. Inoltre, nel nome della foto era contenuto il nome della pizza; così le abbiamo catalogate in cartelle, ma ci siamo resi conto che i nomi non corrispondevano alla realtà e quindi abbiamo dovuto pulire a mano. Alla fine sono rimaste circa 500-600 foto, è chiaro che si tratta di un numero esiguo, ma comunque era sufficiente per distinguere 10 pizze l'una dall'altra.

Per addestrare la rete abbiamo preso la macchina virtuale più economica su Azure con NVIDIA Tesla K80. Lì abbiamo addestrato la rete per 100 epoche, ma era chiaro che la rete era già satura dopo 50 epoche, a causa di un dataset troppo ridotto.

In effetti, il problema principale è l'assenza di buoni dati.

Forse ci siamo confusi un po' nei termini, ma bisogna considerare che non abbiamo esperienza in tutti questi aspetti.

GUI for NOOBS (console per ordinare pizza)

Misha Kumačev (Ceridan), Zen'ja Bikkinin, Zen'ja Vasil'ev

Abbiamo realizzato un prototipo di applicazione console per nerd, grazie al quale è possibile ordinare pizza tramite terminale o linea di comando, o addirittura integrarlo nel pipeline di distribuzione e far consegnare la pizza in ufficio al successo del rilascio.

Il lavoro si è suddiviso in diverse parti: abbiamo analizzato come funziona la nostra API per le applicazioni mobili, abbiamo creato il nostro CLI utilizzando oclif e abbiamo configurato la pubblicazione del pacchetto che abbiamo creato. Con quest'ultimo compito ci sono stati alcuni momenti spiacevoli verso la fine dell'hackathon. Tutto funzionava localmente e anche le vecchie versioni pubblicate del pacchetto funzionavano, ma le nuove (in cui erano state aggiunte più funzionalità interessanti e emoticon) si rifiutavano di funzionare. Abbiamo impiegato circa 40 minuti per capire cosa fosse andato storto, ma alla fine tutto ha magicamente iniziato a funzionare da solo).

Il nostro obiettivo principale per l'hackathon era fare un vero ordine di pizza in ufficio tramite la nostra CLI. Lo abbiamo testato decine di volte su un ambiente di prova, ma avevo comunque le mani tremanti quando digitavo i comandi in produzione.

In conclusione, ce l'abbiamo fatta!

CourierGo

Anton Bruzhmelëv (autore), Vanya Zverev, Gleb Lesnikov (entropia), Andrey Sarafanov

Abbiamo preso l'idea dell'«App per corrieri».

La storia preliminare sulla preparazione.Inizialmente ho considerato quali funzionalità potrebbero esserci nell'app. È emersa all'incirca questa lista di funzionalità:

L'app si collega alla cassa di consegna tramite un codice.
Nell'app sono visibili immediatamente gli ordini disponibili e gli ordini da prendere.
Il corriere segna l'ordine e lo prende in viaggio.
Viene mostrato il tempo stimato e se ce la fa o meno.
Al cliente viene mostrato che il corriere è partito.
Al cliente viene mostrata la posizione del corriere sulla mappa e il tempo stimato.
Il corriere può scrivere al cliente in chat tramite l'app.
Il cliente può scrivere al corriere in chat tramite l'app.
Cinque minuti prima dell'arrivo, il cliente riceve un messaggio che il corriere è vicino, sii pronto.
Il corriere segna nell'app che è arrivato e aspetta.
Il corriere chiama dall'app con un clic e comunica che (sta salendo, è arrivato, ecc.)
Il cliente accetta l'ordine e inserisce il codice PIN dall'app o SMS per confermare la consegna. (come una firma) Affinché il corriere non possa completare la consegna in anticipo se è in ritardo.
L'ordine viene segnato nel sistema come consegnato.

In aggiunta, alcune alternative:

Il corriere può segnare l'ordine come non consegnato e scegliere la ragione.
Il corriere, in caso di ritardo, può emettere un certificato elettronico tramite SMS con un clic. Oppure il certificato arriva automaticamente in caso di mancato rispetto dei tempi di consegna.

La sensazione di potenzialità e necessità di questo progetto, naturalmente, era stimolante.

Il giorno dopo siamo andati a pranzo con il team e abbiamo discusso di come dovrebbe apparire il minimo indispensabile dell'app.

Alla fine si è formata la seguente lista di cose da realizzare durante il hackathon:

Accesso alla cassa di consegna.
Visualizzare la posizione attuale.
Inviare dati a un'API esterna (coordinate, ordine preso, ordine consegnato).
Ricevere dati da un'API esterna (ordini attuali del corriere).
Inviare un evento riguardante che l'ordine è stato preso in consegna / è stato consegnato.
Visualizzare la posizione attuale del corriere sulla mappa del sito.

Il lavoro principale, come si vedeva, sarebbe stato nella creazione del backend e dell'app stessa (dopo discussioni abbiamo scelto ReactNative per lo sviluppo dell'app, per essere precisi un'impostazione sopra di esso — expo.io, permettendo di non scrivere codice nativo). Per quanto riguarda il backend, inizialmente c'era speranza in Vanya Zverev, come esperto nel lavorare con il nostro modello di servizio e k8s (che lavoro ha preso su di sé). Io e Andrey Sarafanov abbiamo iniziato a esplorare ReactNative.

Ho deciso di provare subito a creare un repository funzionante per il progetto. A mezzanotte, mi sono reso conto che in ReactNative la geolocalizzazione funziona male in background, se non si scrive codice nativo, il che mi ha un po' frustrato. Poi mi sono sentito meglio, quando ho capito che stavo leggendo la documentazione del framework expo.io e non quella di ReactNative. Alla fine della serata, era chiaro come ottenere la posizione attuale in expo.io e come creare schermate separate (per il login, visualizzazione ordine, ecc.).

La mattina all'hackathon, abbiamo coinvolto Gleb nel nostro progetto super promettente. Abbiamo rapidamente abbozzato un piano su ciò che doveva essere fatto.

Abbiamo commesso un errore quando, seguendo il modello di progetto, abbiamo cercato di comunicare non tramite HTTP, ma tramite GRPC, poiché nessuno sapeva come costruire un client GRPC per JavaScript. Dopo aver speso circa un'ora e mezza su questo, abbiamo abbandonato l'idea. Per questo motivo, i ragazzi hanno iniziato a rifare il server esistente dal GRPC a WebApi. Dopo mezz'ora, finalmente, siamo riusciti a configurare la comunicazione tra l'applicazione e il backend, oh miracolo. Ma nello stesso momento, Gleb stava quasi completando il deployment su k8s e anche l'autodeploy al commit nel master. 🙂

Per lo storage abbiamo scelto MySQL per non rischiare con il database (c'erano pensieri su CosmosDb).

Alla fine:

Abbiamo implementato il salvataggio delle coordinate attuali del corriere dall'app nell'archivio.
Abbiamo integrato RabbitMQ e ci siamo iscritti ai messaggi di accettazione dell'ordine da parte del corriere, in modo da mostrarlo immediatamente nell'app del corriere.
Abbiamo iniziato a registrare nel nostro database il tempo di consegna dell'ordine, dopo che il corriere premeva il pulsante nell'app. Non siamo riusciti ad aggiungere l'invio dell'evento di ritorno al rabbit riguardo alla consegna dell'ordine.
Ho creato la visualizzazione della mappa nella pagina currentorder del sito con la posizione attuale del corriere. Tuttavia, questa funzionalità è rimasta leggermente incompleta, poiché nell'ambiente non siamo riusciti a configurare CORS per ricevere le coordinate dal nostro nuovo servizio.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Volevamo implementare un provider OpenID Connect, dato che attualmente utilizziamo un protocollo di autenticazione di nostra creazione, il che crea una serie di difficoltà: librerie client personalizzate, lavoro scomodo da parte di partner esterni, possibili problemi di sicurezza (sappiamo che OAuth2.0 e OpenID Connect nella loro implementazione standard possono essere considerati sicuri, ma riguardo alla nostra soluzione, non ne sono sicuro).

Abbiamo creato un servizio separato che emula un servizio di archiviazione dei dati personali, per sviluppare un piccolo modello di provider di autenticazione Country-Agnostic, che estraesse i dati personali da un servizio separato (questo darebbe la possibilità di avere un unico servizio con cui autenticarsi da qualsiasi paese, rimanendo comunque conforme al GDPR e ad altre leggi). Questa parte è stata completata, insieme al provider, e li abbiamo legati con successo. Successivamente, dovevamo creare un'API protetta da token forniti dal provider, supportare la loro introspezione attraverso il provider e restituire dati protetti quando la richiesta soddisfaceva le politiche di autorizzazione (verifichiamo che l'utente sia autenticato secondo lo schema Bearer, che il suo token contenga uno scope specifico + che l'utente stesso abbia il permesso di effettuare la chiamata). Anche questa parte è stata completata. L'ultimo componente era un client JavaScript che riceveva un token, con il quale invocava l'API protetta. Questa parte non siamo riusciti a completarla. Quindi, tutta la parte funzionale era pronta, ma non è stata completata la parte front-end per dimostrare il funzionamento dell'intero sistema.

E-E-E (gioco)

Dima Afonchenko, Sasha Konovalov

Abbiamo creato un mini-gioco in cui mani reattive devono lanciare una salsiccia sulla pizza. Se lanci la salsiccia in modo errato, appare sullo schermo la scritta triste «Scartato», mentre se tutte le salsicce sono lanciate correttamente, appare un fatto casuale sulla pizza.

Volevamo creare un secondo livello in cui lanciare pomodori, ma non siamo riusciti.

Un breve seguito: chi ha vinto?

Prima dell'hackathon abbiamo parlato con i ragazzi e ho chiesto quale premio avrebbero voluto ricevere in caso di vittoria. È risultato che il premio più prezioso sarebbe «la strada per la produzione».

Pertanto, aspettatevi a breve un annuncio riguardo al gioco con i manici che distribuiscono peperoni sulla pizza.