Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratie

Onlangs hebben we vertelde over het corporate masterprogramma van JetBrains en ITMO University “Software Development / Software Engineering”. Wij nodigen alle geïnteresseerden uit voor een open dag op maandag 29 april. We vertellen je over de voordelen van ons masterprogramma, welke bonussen we studenten bieden en wat we daarvoor terugvragen. Daarnaast zullen wij zeker vragen van onze gasten beantwoorden.

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratieDe open dag wordt gehouden op het kantoor van JetBrains in het Times Business Center, waar onze masterstudenten studeren. Begint om 17:00 uur. Op de website vindt u alle details en kunt u zich inschrijven voor het evenement mse.itmo.ru. Kom en je zult er geen spijt van krijgen!

Een van de belangrijkste onderdelen van het programma is oefenen. Studenten hebben er veel van: wekelijks huiswerk, semesterprojecten en hackathons. Dankzij de volledige onderdompeling in moderne ontwikkelingsmethodologieën en -technologieën tijdens hun studie, integreren afgestudeerden snel in de werkprocessen van grote IT-bedrijven.

In dit bericht willen we meer in detail praten over DevDays-hackathons, die elke zes maanden plaatsvinden. De regels zijn simpel: teams van 3-4 personen verzamelen zich en gedurende drie dagen brengen studenten hun eigen ideeën tot leven. Wat zou hiervan kunnen komen? Lees het eerste deel van de verhalen over de hackathonprojecten van dit semester van de studenten zelf :)

Dagboek met filmaanbevelingen

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratie

Idee auteur
Ivan Ilchuk
Team samenstelling
Ivan Ilchuk - parseren van filmplots, server
Vladislav Korablinov – ontwikkeling van modellen voor het vergelijken van de nabijheid van een dagboekaantekening en de plot van een film
Dmitry Valchuk – gebruikersinterface
Nikita Vinokurov – gebruikersinterface, ontwerp

Het doel van ons project was om een ​​desktopapplicatie te schrijven: een dagboek dat de gebruiker films zou aanbevelen op basis van de vermeldingen daarin.

Dit idee kwam bij mij op toen ik op weg was naar de universiteit en nadacht over mijn problemen. “Met welk probleem iemand ook wordt geconfronteerd, een klassieke schrijver heeft er al over geschreven”, dacht ik. “En aangezien iemand het heeft geschreven, betekent dit dat iemand het al heeft gefilmd.” Dus de wens om een ​​film te kijken over een persoon met dezelfde mentale kwelling leek natuurlijk.

Uiteraard is er een grote verscheidenheid aan afzonderlijke dagboeken en afzonderlijke aanbevelingsdiensten (maar meestal zijn de aanbevelingen gebaseerd op wat de persoon eerder leuk vond). In principe heeft dit project iets gemeen met het zoeken naar een film op basis van belangrijke punten, maar toch biedt onze applicatie in de eerste plaats de functionaliteit van een dagboek.

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratieHoe hebben we dit geïmplementeerd? Wanneer u op de magische knop drukt, stuurt het dagboek een vermelding naar de server, waar de film wordt geselecteerd op basis van de beschrijving van Wikipedia. Onze frontend is gemaakt in Electron (we gebruiken deze, niet de website, omdat we aanvankelijk besloten om gebruikersgegevens niet op de server op te slaan, maar lokaal op de computer), en de server en het aanbevelingssysteem zelf zijn gemaakt in Python: TF's waren verkregen uit de beschrijvingen -IDF-vectoren die werden vergeleken op nabijheid van de dagboekinvoervector.

Eén teamlid werkte alleen aan het model, de ander werkte geheel aan de front-end (aanvankelijk samen met een derde lid, die later overstapte naar testen). Ik was bezig met het ontleden van filmplots van Wikipedia en de server.

Stap voor stap kwamen we dichter bij het resultaat en overwonnen we een aantal problemen, te beginnen met het feit dat het model aanvankelijk veel RAM nodig had, eindigend met de moeilijkheid om gegevens naar de server over te brengen.

Om een ​​film voor vanavond te vinden, heb je niet veel moeite nodig: het resultaat van ons driedaagse werk is een desktopapplicatie en een server, waartoe de gebruiker toegang heeft via https, en als reactie daarop een selectie van 5 films ontvangt met een korte beschrijving en een poster.

Mijn indrukken van het project zijn zeer positief: het werk was boeiend van 's morgens vroeg tot' s avonds laat, en de resulterende toepassing levert periodiek uiterst grappige resultaten op in de stijl van "Sleepless Night" voor een dagboekaantekening over huiswerk op de universiteit of een film over de eerste schooldag voor een verhaal over de eerste dag op de afdeling.

Relevante links, installatieprogramma's, etc. zijn te vinden hier.

Routegenerator

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratieIdee auteur
Artemyeva Irina
Team samenstelling
Artemyeva Irina – teamleider, hoofdlus
Gordeeva Ljoedmila – muziek
Platonov Vladislav – routes

Ik hou er echt van om door de stad te lopen: naar gebouwen kijken, naar mensen, nadenken over de geschiedenis. Maar zelfs als ik van woonplaats verander, word ik vroeg of laat geconfronteerd met het probleem van het kiezen van een route: ik heb alle routes voltooid die ik kon bedenken. Zo ontstond het idee om het genereren van routes te automatiseren: jij geeft het startpunt en de lengte van de route aan, en het programma geeft je een optie. Wandelingen kunnen lang zijn, dus een logische ontwikkeling van het idee lijkt de mogelijkheid toe te voegen om tussenpunten aan te geven voor een “stop”, waar je een hapje kunt eten en kunt uitrusten. Een andere tak van ontwikkeling was muziek. Lopen op muziek is altijd leuker, dus het zou geweldig zijn om de mogelijkheid toe te voegen om een ​​afspeellijst te selecteren op basis van een gegenereerde route.

Het was niet mogelijk om dergelijke oplossingen te vinden in de bestaande toepassingen. De dichtstbijzijnde analogen zijn alle routeplanners: Google Maps, 2GIS, enz.

Het is het handigst om zo’n applicatie op je telefoon te hebben, dus het gebruik van Telegram was een goede optie. Hiermee kun je kaarten weergeven en muziek afspelen, en je kunt dit allemaal besturen door een bot te schrijven. Het belangrijkste werk met kaarten werd gedaan met behulp van de Google Map API. Python maakt het eenvoudig om beide technologieën te combineren.

Er waren drie mensen in het team, dus de taak werd verdeeld in twee niet-overlappende subtaken (werken met kaarten en werken met muziek), zodat de jongens onafhankelijk konden werken, en ik nam de taak op mij om de resultaten te combineren.

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratieNiemand van ons had ooit met de Google Map API of met geschreven Telegram-bots gewerkt, dus het grootste probleem was de hoeveelheid tijd die werd besteed aan de implementatie van het project: iets begrijpen kost altijd meer tijd dan iets doen dat je goed kent. Ook was het lastig om de Telegram bot API te kiezen: door blokkering werken ze niet allemaal en moest ik moeite doen om alles in te stellen.

Het is de moeite waard om apart te vermelden hoe het probleem van het genereren van routes werd opgelost. Een route bouwen tussen twee locaties is eenvoudig, maar wat kun je de gebruiker bieden als alleen de lengte van de route bekend is? Laat de gebruiker 10 kilometer willen lopen. Er wordt een punt in een willekeurige richting geselecteerd, waarvan de afstand in een rechte lijn 10 kilometer is, waarna een route naar dit punt langs echte wegen wordt opgebouwd. Hoogstwaarschijnlijk zal het niet recht zijn, daarom zullen we het inkorten tot de aangegeven 10 kilometer. Er zijn veel opties voor dergelijke routes - we hebben een echte routegenerator!

Aanvankelijk wilde ik de kaart segmenteren in gebieden die overeenkomen met groene gebieden: dijken, binnenplaatsen, straten, om de meest aangename route voor een wandeling te krijgen, en ook muziek genereren in overeenstemming met deze gebieden. Maar dit doen met de Google Map API bleek lastig (we hadden geen tijd om dit probleem op te lossen). Wel was het mogelijk om de aanleg van een route door specifieke typen locaties (winkel, park, bibliotheek) uit te voeren: als de route langs alle aangegeven plekken gaat, maar de gewenste afstand nog niet is afgelegd, wordt deze afgerond tot een door de gebruiker opgegeven afstand in een willekeurige richting. Met de Google Map API kun je bovendien de geschatte reistijd berekenen, waardoor je precies voor de hele wandeling een playlist kunt kiezen.

Dientengevolge erin geslaagd een generatie te maken routes op startpunt, afstand en tussenpunten; alles was voorbereid om muziek in te delen volgens trajectonderdelen, maar door tijdgebrek werd besloten om de mogelijkheid om een ​​afspeellijst te selecteren gewoon als extra UI-tak te laten staan. Zo kon de gebruiker zelfstandig de muziek kiezen waarnaar hij wilde luisteren.

Het grootste probleem bij het werken met muziek was dat je niet wist waar je mp3-bestanden vandaan kon halen zonder dat de gebruiker een account bij een dienst moest hebben. Er werd besloten om muziek van de gebruiker op te vragen (UserMusic-modus). Hierdoor ontstaat een nieuw probleem: niet iedereen heeft de mogelijkheid om nummers te downloaden. Eén oplossing is het creëren van een repository met muziek van gebruikers (BotMusic-modus) - daaruit kun je muziek genereren, ongeacht de services.

Hoewel niet perfect, hebben we de taak voltooid: we eindigden met een applicatie die ik graag zou willen gebruiken. Over het algemeen is dit erg gaaf: drie dagen geleden had je alleen een idee en geen enkele gedachte over hoe je het precies moest implementeren, maar nu is er een werkende oplossing. Dit waren drie belangrijke dagen voor mij. Ik ben niet langer bang om iets te bedenken waarvan ik niet genoeg kennis heb om het uit te voeren, het was ongelooflijk interessant om teamleider te zijn en ik heb de geweldige jongens leren kennen die mijn team kwamen versterken beter!

Vloeibare democratie

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratie

Idee auteur
Stanislav Sychev
Team samenstelling
Stanislav Sychev – teamleider, database
Nikolay Izyumov – botinterface
Anton Rjabusjev – backend

Binnen verschillende groepen is er vaak behoefte om een ​​besluit te nemen of te stemmen. Meestal nemen ze in dergelijke gevallen hun toevlucht directe democratieWanneer de groep echter groot wordt, kunnen er problemen ontstaan. Het kan bijvoorbeeld zijn dat een persoon in een groep niet vaak vragen wil beantwoorden of vragen over bepaalde onderwerpen wil beantwoorden. In grote groepen, om problemen te voorkomen, nemen ze hun toevlucht representatieve democratie, wanneer uit alle mensen een aparte groep ‘afgevaardigden’ wordt gekozen, die de rest bevrijden van de last van keuze. Maar het is nogal moeilijk om zo'n plaatsvervanger te worden, en de persoon die er een wordt, zal niet noodzakelijkerwijs eerlijk en respectabel zijn, zoals hij voor de kiezers leek.

Om de problemen van beide systemen op te lossen, stelde Brian Ford het concept voor vloeibare democratie. In een dergelijk systeem is iedereen vrij om de rol van een gewone gebruiker of een afgevaardigde te kiezen, simpelweg door zijn of haar wens kenbaar te maken. Iedereen kan zelfstandig stemmen of een stem uitbrengen aan een afgevaardigde over één of meerdere onderwerpen. Ook een afgevaardigde kan zijn stem uitbrengen. Bovendien kan de stem op elk moment worden ingetrokken als de afgevaardigde niet langer bij de kiezer past.

Voorbeelden van het gebruik van vloeibare democratie zijn te vinden in de politiek, en we wilden een soortgelijk idee implementeren voor dagelijks gebruik binnen allerlei groepen mensen. Tijdens de volgende DevDays-hackathon besloten we een Telegram-bot te schrijven om te stemmen volgens de principes van de vloeibare democratie. Tegelijkertijd wilde ik een veel voorkomend probleem met dergelijke bots vermijden: de algemene chat verstoppen met berichten van de bot. De oplossing is om zoveel mogelijk functionaliteit in een persoonlijk gesprek te brengen.

Hackathon DevDays'19 (deel 1): een dagboek met aanbevelingen, een wandelroutegenerator en vloeibare democratieOm deze bot te maken hebben we gebruikt API van Telegram. Er werd gekozen voor een PostgreSQL-database om de geschiedenis van stemmingen en delegaties op te slaan. Om met de bot te communiceren, werd een Flask-server geïnstalleerd. We hebben voor deze technologieën gekozen omdat... tijdens onze masterstudies hadden we al ervaring met de interactie met hen. Het werk aan de drie componenten van het project – de database, de server en de bot – werd met succes onder de teamleden verdeeld.

Drie dagen is natuurlijk kort, dus tijdens de hackathon hebben we het idee tot op prototypeniveau geïmplementeerd. Als gevolg hiervan hebben we een bot gemaakt die alleen informatie naar de algemene chat schrijft over het openen van de stemming en de anonieme resultaten ervan. De mogelijkheid om te stemmen en een opiniepeiling te maken wordt geïmplementeerd via persoonlijke correspondentie met de bot. Om te stemmen voert u een opdracht in die een lijst met kwesties weergeeft die directe aandacht vereisen. In persoonlijke correspondentie kunt u de lijst met afgevaardigden en hun eerdere stemmen bekijken, en hen ook uw stem geven over een van de onderwerpen.

Video met een voorbeeld van werk.

Het was interessant om aan het project te werken, we bleven tot middernacht op de universiteit. We denken dat dit een geweldige manier is om even tussendoor te studeren, ook al is het erg vermoeiend. Het was een prettige ervaring om in een hecht team te werken.

PS. De inschrijving voor masteropleidingen voor volgend studiejaar is al gedaan is open. Sluit je nu aan!

Bron: www.habr.com

Voeg een reactie