Kodim-pico

Saluton, Habr. Ni spontanee okazigis nian unuan internan hakatonon. Mi decidis dividi kun vi miajn dolorojn kaj konkludojn pri preparo por ĝi en 2 semajnoj, kaj ankaŭ la projektojn kiuj rezultis.

La enuiga parto por tiuj, kiuj interesiĝas pri merkatado

Mi komencos per eta rakonto.

Komenco de aprilo. La unua MskDotNet Community hackathon okazas en nia oficejo. La Batalo de Tatooine estas en plena svingo en nia galaksio ĉi-foje. sabato. 20 teamoj. Pico. Ĉio estas tre sincera (pruvoj). Ŝvelebla R2-D2 flosas ĉirkaŭ la halo. Teamoj skribas la plej ĝustajn algoritmojn por trapasi la plej danĝeran vetkuron sur la mapo. Ni movas la lanĉon de la unuaj vetkuroj. Kuketoj kaj kafo estas savantoj. La organizantoj kaj mi atendis, ke multaj homoj foriros post tagmanĝo sabate. Sed ne. 12 horoj da kodado malantaŭe. La finalo. Io defalas, io ne komenciĝas. Sed ĉiuj estas feliĉaj. Nia teamo venkas. Ni estas duoble feliĉaj.

Mi dividas mian ĝojon pri Slack kaj venas al la menso la ideo: "Ni devas fari nian propran hakatonon." Mi skribas al nia servostacio Sasha. Silento.

Mateno. Mi trinkas kafon en la oficejo. Mi vidas Sasha alproksimiĝi de malantaŭe. “Lisa, ĉi tio estas bonega! Ni havas gravan daton la 21-an de aprilo. Ni faru ĝin!" WTF!? Tiel rapide? A? Kio? Mi devas flugi al Syktyvkar por staĝo meze de aprilo. Kaj al la diablo kun ĝi! Ni.

2 semajnoj restas. Mi neniam estis la sola organizanto de hakatono. Estu interna. Mi legis artikolojn pri ĉi tiu temo. Malmola. Ĝi prenas plurajn monatojn. Pluraj homoj estas bezonataj. Vi devas pensi pri komercaĵoj, premioj, kondiĉoj, horaro, intereso, kompreni la celon, buĝetojn. Aŭ eble eĉ eltrovi la signifon de vivo. Mi certe ne sukcesos ĝustatempe. Kaj dum vi legis kaj preparis, jam pasis semajno. Estas tempo forgesi pri la artikoloj kaj ekfari ion.

Kaptu nian kontrolon por okazigi internan hakatonon en 1 semajno

• Plano: Vi sidas trankvile kaj verkas liston de tio, kion oni devas fari por la hakatono. 30-minutoj.
• Objektivo: Partoprenantoj proponas kaj elektas la projektojn, kiujn ili volas krei en Google Sheets. Fona tasko, 2 horoj.
• Horaro: sur via genuo vi skribas mallongan disrompon de tempo, konsiderante 3 paŭzojn kaj la finalon. 20-minutoj.
• Teamoj: publikigu mesaĝon pri la hakatono kun horaro de la servostacio en IT-kanaloj en Slack/mail/ktp kaj kreu apartan kanalon por la hakatono. En ĝi, ĉiuj estas dividitaj en teamojn, kaj tiuj, kiuj estas nedeciditaj, faras tion en la unuaj 5 minutoj de la hakatono. Fona tasko, 2 horoj.
• Bulkoj: vi elpensas varon kun du programistoj, donas ĝin al la dezajnisto por bildigo, kaj ricevas ĝin preta. Fona tasko, 3 tagoj.
• Hackathon: vi venas al la oficejo, kunordigas ĉiujn komence, iras pri via komerco, legas Reddit, grave anoncas ĉiun paŭzon pri freŝa pico, fotu la sunsubiro, anoncas la finalon, voĉdonas kune kaj elektas la gajninton. 1-tago.
• Sub la asterisko: Kompreneble, vi konstante pensas pri ĉio bone. Kompreneble, ne ĉiuj vidos vian mesaĝon kaj estas pli bone paroli kun iuj persone. Kompreneble, se iu helpos vin, ĉio fariĝos 2 fojojn pli facila (la mirinda Alena helpis min).

La malpli enuiga parto pri la hakatona dato

Kial la 21-an de aprilo? Ĉi tiu tago estas grava por ni. Ĝuste antaŭ unu jaro, la 21-an de aprilo, ni falis sub ŝarĝon dum la unua semajnfino post la komenco de la Federacia Reklama Kampanjo. La sekvan tagon, dimanĉon, nia teamo laboris ekde la 8-a matene. Tiam ni kreis sundayhackathon-estraron en Trello kaj semajno da deĵorlaboro komenciĝis, 12 horojn tage. La situacio estis tiel kritika ke ni eĉ ne havis tempon por manĝi kaj ni estis nutritaj de uloj de aliaj teamoj.

Vi povas legi pli detalan rakonton ĉe Paĝo de Fjodor Ovĉinnikov (nia CEO). Ekde tiam ni multe ŝanĝiĝis, sed nun ni certe ne forgesos la daton.

Ĉi-jare, ni decidis, ke ĉi tiu evento indas eternigi en la memoro de la posteularo kaj, laŭ la plej bonaj tradicioj, ni organizis la unuan internan hakatonon en la historio de Dodo, kiu daŭris 10 horojn.

La plej enuiga parto pri hackathon-projektoj

Malgarantio: ĉiuj priskriboj estis skribitaj de la uloj mem, do la aŭtoreco de la teksto ne estas mia.

Oleg Learning (maŝinlernado)

Dima Kochnev, Sasha Andronov (@alexandronov)

Ili volis fari neŭralan reton, kiu determinus kia pico estas en foto sen iu ajn scio. Kiel rezulto, ni faris tre simplan kaj ludilan unu - ĝi rekonas 10 picojn, ni proksimume eltrovis kiel ĉio funkcias, laŭeble en tago (~10 horoj).

Precipe ni rimarkis, ke la industrio atingis nivelon, kie ordinara programisto povas preni pretajn bibliotekojn, legi la dokumentaron kaj trejni sian neŭralan reton sen profunda scio pri la temo. Kaj ĝi funkcios sufiĉe bone por solvi verajn problemojn.

Iloj uzataj:

• imageai — oportuna kaj simpla biblioteko por labori kun maŝinlernado kaj komputila vizio.
• Ni provis du modelojn - ResNet50, Yolo.
• La kodo estis skribita, kompreneble, en Python.

Ni havis 11000 3 fotojn, sed preskaŭ 4/500 el ili montriĝis rubo, kaj la ceteraj havis malsamajn, netaŭgajn angulojn. Rezulte, ni prenis pretan modelon (kiu simple scias trovi picon) kaj per ĝia helpo ni apartigis la rubon. Poste, la titolo de la foto inkludis la nomon de la pico - do ni ordigis ĝin en dosierujojn, sed montriĝis, ke la nomoj ne koincidis kun la realo kaj ni devis purigi ĝin per niaj manoj. Fine restis ĉirkaŭ 600-10 fotoj, estas klare, ke tio estas negrava kvanto, sed tamen tio sufiĉis por apartigi XNUMX picojn unu de la alia.

Por trejni la kradon, ni prenis la plej malmultekostan virtualan maŝinon en Azure sur NVIDIA Tesla K80. Ili trejniĝis pri ĝi dum 100 epokoj, sed estis klare, ke la reto estas trosaturita post 50 epokoj, pro la fakto ke estis malgranda datumaro.

Fakte, la tuta problemo estas la manko de bonaj datumoj.

Ni eble iomete konfuzis la terminojn, sed ni devas konsideri, ke ni tute ne havas sperton pri laboro kun ĉiuj ĉi aferoj.

GUI por NOOBS (konzolo por mendi picon)

Miŝa Kumaĉev (Ceridan), Ĵenja Bikkinin, Ĵenja Vasiliev

Ni kunmetis prototipon de konzola aplikaĵo por geeks, danke al kiu vi povas mendi picon per la terminalo aŭ komandlinio, aŭ eĉ integri ĝin en la disfaldan dukton kaj, post sukcesa liberigo, liveri picon al la oficejo.

La laboro estis dividita en plurajn partojn: ni eksciis kiel funkcias nia API por moveblaj aplikoj, kunvenis nian propran CLI uzante oklifo kaj agordis la publikigon de la pako, kiun ni kolektis. La lasta tasko implikis kelkajn malagrablajn minutojn al la fino de la hakatono. Ĉio funkciis loke por ni, kaj eĉ la malnovaj publikigitaj versioj de la pakaĵo funkciis, sed la novaj (kiuj aldonis pli bonegajn funkciojn kaj miensimbolojn) rifuzis funkcii. Ni pasigis ĉirkaŭ 40 minutojn por eltrovi kio misfunkciis, sed finfine ĉio magie funkciis memstare).

Nia maksimuma programo por la hakatono estis vera mendo de pico al la oficejo per nia CLI. Ni prizorgis ĉion dekdufoje sur la testbenko, sed miaj manoj ankoraŭ tremis kiam mi enmetis komandojn en produktado.

Kiel rezulto, ni finfine faris ĝin!

KurieroIru

Anton Bruĵmelev (verkinto), Vanja Zverev, Gleb Lesnikov (entropio), Andrej Sarafanov

Ni prenis la ideon de "Apo por Kuriero".

Fono pri preparado.Komence, mi scivolis, kiaj funkcioj povus esti en la aplikaĵo? La sekva listo de funkcieco aperis:

• La aplikaĵo ensalutas en la liveran kasregistrilon uzante la kodon.
• La aplikaĵo tuj montras disponeblajn mendojn kaj mendojn, kiuj devas esti prenitaj.
• La kuriero notas la mendon kaj prenas ĝin dum la vojaĝo.
• Oni montras al li la laŭtaksan tempon kaj ĉu li ĝustatempe aŭ ne.
• Montras al la kliento, ke la kuriero foriris.
• La kliento komencas montri la punkton de la kuriero sur la mapo kaj la laŭtaksa tempo.
• La kuriero povas skribi al la kliento en babilejo de la aplikaĵo.
• La kliento povas skribi al la kuriero per babilejo de la aplikaĵo.
• Kvin minutojn antaŭ la alveno, la kliento ricevas mesaĝon, ke la kuriero estas proksima, estu preta.
• La kuriero notas en la aplikaĵo, ke li alvenis kaj atendas.
• La kuriero vokas de la aplikaĵo per unu klako kaj raportas ke (leviĝas, alvenis, ktp.)
• La kliento akceptas la mendon kaj enmetas PIN-kodon de la aplikaĵo aŭ SMS por konfirmi liveron.(kiel subskribo) Por ke la kuriero ne povas plenumi la transdonon anticipe se li malfruiĝas.
• La mendo estas markita kiel liverita en la sistemo.

Krome kelkaj alternativaj scenaroj:

• La kuriero povas marki la mendon kiel neliverita kaj elekti la kialon.
• Se vi malfruas, la kuriero povas elsendi elektronikan atestilon per SMS kun unu butono. Aŭ la atestilo alvenas aŭtomate se la limdato ne estas plenumita.

La sento de promeso kaj neceso de tiu ĉi projekto estis, kompreneble, vigliga.

La sekvan tagon ni tagmanĝis kun la teamo kaj diskutis kiel aspektus la minimuma funkcieco de la aplikaĵo.

Kiel rezulto, la sekva listo de kio devis esti farita ĉe la hakatono estis formita:

• Ensalutu al la livera kasregistrilo.
• Montru aktualan pozicion.
• Sendu datumojn al ekstera API (koordinatoj, ricevis la mendon, liveris la mendon).
• Ricevu datumojn de ekstera API (nuntempaj kurieraj mendoj).
• Sendu eventon indikante, ke vi prenis la mendon por livero/liverita.
• Montru la nunan pozicion de la kuriero sur la mapo sur la retejo.

La ĉefa laboro, kiel ŝajnis, kuŝis en kreado de la backend, la aplikaĵo mem (post diskutoj, ni elektis ReactNative por disvolvi la aplikaĵon, aŭ pli ĝuste la kadron por ĝi - ekspo.io, kiu permesas vin tute ne skribi denaskan kodon). Koncerne la backend, komence estis espero en Vanya Zverev, ĉar li estis sperta pri laboro kun nia servo ŝablono kaj k8s (kiun taskon li prenis). Andrey Sarafanov kaj mi prenis ReactNative por turno.

Mi decidis provi tuj krei laboran deponejon por la projekto mem. Je la 12-a nokte mi renkontis la fakton, ke geolokigo en la fono ne bone funkcias en ReactNative, se vi ne skribas denaskan kodon, mi estis iom frustrita. Tiam mi ellasis, kiam mi konstatis, ke mi legas la dokumentadon ne de la kadro expo.io, sed de ReactNative. Rezulte, dum la vespero mi jam komprenis kiel akiri la nunan pozicion en expo.io kaj desegni apartajn ekranojn (por ensaluto, mendo-montrado ktp.).

Matene ĉe la hakatono, ili logis Gleb en sian superpromesplenan projekton. Ili rapide elpensis planon pri tio, kion oni devis fari.

Ni eraris kiam, laŭ la projekta ŝablono, ni provis komuniki ne per HTTP, sed per GRPC, ĉar neniu sciis konstrui GRPC-klienton por JavaScript. Fine, pasiginte ĉirkaŭ unu horon kaj duonon pri tio, ni forlasis ĉi tiun ideon. Pro tio, la uloj sur la malantaŭo komencis refari la pretan servilon de GRPC al WebApi. Post duonhoro, ni finfine povis agordi komunikadon inter la aplikaĵo kaj la backend, jen. Sed samtempe, Gleb preskaŭ finis la deplojon al k8s kaj plie la aŭtomatan deplojon de kompromiso al la majstro. 🙂

Ni elektis MySQL kiel stokadon por ne riski almenaŭ kun la datumbazo (ni pensis pri CosmosDb).

Eventuale:

• Efektivigita konservado de la nunaj koordinatoj de la kuriero de la aplikaĵo al la datumbazo.
• Ni instalis RabbitMQ kaj abonis mesaĝojn pri la kuriero prenanta mendon por tuj montri la mendon de la kuriero en la aplikaĵo.
• Ni komencis ŝpari la ordon-livertempon en nia datumbazo post kiam la kuriero premis butonon en la aplikaĵo. Ni ne havis tempon aldoni sendi eventon reen al la rebbito, ke la mendo estis liverita.
• Mi faris mapmontrilon sur la nuna ordopaĝo en la retejo kun la nuna pozicio de la kuriero. Sed ĉi tiu funkcio restis iom nefinita, ĉar ne eblis agordi CORS en la medio por ricevi koordinatojn de nia nova servo.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artjom Trofimuŝkin

Ni volis efektivigi OpenID Connect-provizanton, ĉar nuntempe ni uzas aŭtentikan protokolon de nia propra dezajno, kaj tio kreas kelkajn malfacilaĵojn: kutimaj klientbibliotekoj, maloportuna laboro fare de eksteraj partneroj, eblaj sekurecaj problemoj (finfine. , OAuth2.0 kaj OpenID Connect en la referenca efektivigo povas esti konsiderataj sekuraj, sed mi ne certas pri nia solvo).

Ni faris apartan servon imitantan servon por stoki personajn datumojn por krei malgrandan Land-Agnostikan modelon de aŭtentikigprovizanto, kiu irus al aparta servo por personaj datumoj (ĉi tio estonte ebligus havi unu servon kun kiun oni povus ensaluti per konta registriĝo en iu ajn lando, kaj samtempe observi GDPR kaj aliajn federaciajn leĝojn). Ni faris ĉi tiun parton, same kiel la provizanto, kaj sukcese ligis ilin unu kun la alia. Poste, estis necese krei API, kiu estus protektita per ĵetonoj eldonitaj de la provizanto, subteni ilian introspekton per la provizanto kaj redoni protektitajn datumojn se la peto kontentigis la rajtigajn politikojn (ni kontrolas, ke la uzanto estas aŭtentikigita laŭ la Bearer-skemo). , lia signo enhavas certan amplekson + y La uzanto mem havas permeson, kiu permesas fari la vokon). Ĉi tiu parto ankaŭ estis kompletigita. La lasta komponanto estis JavaScript-kliento, kiu ricevus ĵetonon, kun la helpo de kiu ĝi nomus protektita API. Ni ne havis tempon por fari ĉi tiun parton. Tio estas, la tuta funkcia parto estis preta, sed la antaŭa parto ne estis preta pruvi la funkciecon de la tuta sistemo.

E-E-E (ludilo)

Dima Afonĉenko, Saŝa Konovalov

Ni faris mini-ludilon sur yunka kie gajaj manoj ĵetas kolbason sur picon. Se vi surmetas la kolbason malĝuste, malĝoja "Malakceptita" mesaĝo aperas sur la ekrano, kaj se la tuta kolbaso estis surmetita ĝuste, hazarda fakto pri pico aperas.

Ni volis fari duan nivelon per ĵetado de tomatoj, sed ni ne havis tempon.

Mallonga daŭrigo: kiu venkis?

Antaŭ la hakatono, ni parolis kun la uloj kaj mi demandis, kian premion ili ŝatus ricevi se ili venkas. Montriĝis, ke la plej valora premio estus "la vojo al manĝaĵo".

Sekve, atendu, ke ni baldaŭ anoncos ludon kun manoj, kiuj metas paprikojn sur picon.

Kiel atentema leganto eble rimarkis, venkis la teamo "E-E-E (ludilo)". Gratulon infanoj!

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Kiun projekton vi plej ŝatis?

• Oleg Learning (maŝinlernado)

• GUI por NOOBS

• KurieroIru

• M87

• E-E-E

Voĉdonis 5 uzantoj. 3 uzantoj sindetenis.

fonto: www.habr.com