Nyligen vi om företagsmasterprogrammet för JetBrains och ITMO University "Software Development / Software Engineering". Vi inbjuder alla intresserade till en öppen dag måndagen den 29 april. Vi kommer att berätta om fördelarna med vårt masterprogram, vilka bonusar vi erbjuder studenter och vad vi kräver i gengäld. Dessutom kommer vi definitivt att svara på frågor från våra gäster.
Den öppna dagen kommer att hållas på JetBrains kontor i Times Business Center, där våra masterstudenter studerar. Börjar kl 17. Du kan ta reda på alla detaljer och anmäla dig till evenemanget på hemsidan . Kom och du kommer inte ångra dig!
En av huvudkomponenterna i programmet är övning. Studenter har mycket av det: läxor varje vecka, terminsprojekt och hackathons. Tack vare fullständig nedsänkning i moderna utvecklingsmetoder och -teknologier under sina studier, integreras akademiker snabbt i arbetsprocesserna hos stora IT-företag.
I det här inlägget vill vi prata mer i detalj om DevDays hackathons, som äger rum var sjätte månad. Reglerna är enkla: team om 3-4 personer samlas och under tre dagar förverkligar eleverna sina egna idéer. Vad kan komma av detta? Läs den första delen av berättelser om terminens hackathonprojekt från studenterna själva :)
Dagbok med filmrekommendationer
Idéns författare
Ivan Ilchuk
Lagkomposition
Ivan Ilchuk – filmplotsanalys, server
Vladislav Korablinov - utveckling av modeller för att jämföra närheten till en dagboksanteckning och handlingen i en film
Dmitry Valchuk – UI
Nikita Vinokurov – UI, design
Målet med vårt projekt var att skriva en skrivbordsapplikation - en dagbok som skulle rekommendera filmer till användaren baserat på inläggen i den.
Den här idén kom till mig när jag var på väg till universitetet och funderade på mina problem. "Vilket problem en person än möter, har någon klassisk författare redan skrivit om det," tänkte jag. "Och eftersom någon skrev det betyder det att någon redan har filmat det." Så önskan att se en film om en person med samma psykiska plåga dök upp naturligt.
Uppenbarligen finns det ett brett utbud av separata dagböcker och separata rekommendationstjänster (men vanligtvis är rekommendationerna baserade på vad personen tidigare gillade). I princip har det här projektet något gemensamt med att söka efter en film efter nyckelpunkter, men ändå, för det första, tillhandahåller vår applikation funktionaliteten hos en dagbok.
Hur genomförde vi detta? När du trycker på den magiska knappen skickar dagboken ett inlägg till servern, där filmen väljs ut utifrån beskrivningen hämtad från Wikipedia. Vår frontend gjordes i Electron (vi använder den, inte webbplatsen, eftersom vi från början bestämde oss för att lagra användardata inte på servern, utan lokalt på datorn), och själva servern och rekommendationssystemet gjordes i Python: TFs var erhållna från beskrivningarna -IDF-vektorer som jämfördes för närhet till dagboksinmatningsvektorn.
En gruppmedlem arbetade bara på modellen, den andra arbetade helt och hållet på fronten (till en början tillsammans med en tredje medlem, som senare gick över till att testa). Jag var engagerad i att analysera filmintriger från Wikipedia och servern.
Steg för steg kom vi närmare resultatet och övervann ett antal problem, som började med det faktum att modellen initialt krävde mycket RAM, slutade med svårigheten att överföra data till servern.
Nu, för att hitta en film för kvällen, behöver du inte mycket ansträngning: resultatet av vårt tre dagar långa arbete är en skrivbordsapplikation och en server, som användaren kommer åt via https, och som svar får ett urval av 5 filmer med en kort beskrivning och en affisch.
Mina intryck av projektet är mycket positiva: arbetet var fängslande från tidig morgon till sent på kvällen, och den resulterande applikationen ger periodvis extremt roliga resultat i stil med "Sömnlös natt" för en dagboksanteckning om läxor på universitetet eller en film om första skoldagen för en berättelse om första dagen på institutionen.
Relevanta länkar, installatörer etc. kan hittas .
Ruttgenerator
Idéns författare
Artemyeva Irina
Lagkomposition
Artemyeva Irina – lagledare, huvudslinga
Gordeeva Lyudmila – musik
Platonov Vladislav – rutter
Jag gillar verkligen att gå runt i staden: titta på byggnader, människor, tänka på historien. Men även när jag byter bostadsort ställs jag förr eller senare inför problemet med att välja en rutt: jag har genomfört alla de jag kunde tänka mig. Så här kom idén att automatisera genereringen av rutter: du anger startpunkten och längden på rutten, och programmet ger dig en möjlighet. Promenader kan vara långa, så en logisk utveckling av idén verkar vara att lägga till möjligheten att ange mellanliggande punkter för ett "stopp", där du kan ta ett mellanmål och vila. En annan gren av utvecklingen var musiken. Att gå till musik är alltid roligare, så det skulle vara bra att lägga till möjligheten att välja en spellista baserat på en genererad rutt.
Det var inte möjligt att hitta sådana lösningar bland befintliga applikationer. De närmaste analogerna är alla ruttplanerare: Google Maps, 2GIS, etc.
Det är mest bekvämt att ha en sådan applikation på din telefon, så att använda Telegram var ett bra alternativ. Den låter dig visa kartor och spela musik, och du kan styra allt detta genom att skriva en bot. Huvudarbetet med kartor gjordes med hjälp av Google Map API. Python gör det enkelt att kombinera båda teknikerna.
Det var tre personer i teamet, så uppgiften var uppdelad i två icke-överlappande deluppgifter (att arbeta med kartor och arbeta med musik) så att killarna kunde arbeta självständigt, och jag tog på mig att kombinera resultaten.
Ingen av oss hade någonsin arbetat med Google Maps API eller skrivit Telegram-bots, så huvudproblemet var hur lång tid som tilldelades för att implementera projektet: att förstå något tar alltid mer tid än att göra något du kan väl. Det var också svårt att välja Telegram bot API: på grund av blockering fungerar inte alla och jag var tvungen att kämpa för att ställa in allt.
Det är värt att nämna separat hur problemet med att generera rutter löstes. Det är lätt att bygga en rutt mellan två platser, men vad kan du erbjuda användaren om bara längden på rutten är känd? Låt användaren vilja gå 10 kilometer. En punkt väljs i en godtycklig riktning, vars avstånd i en rak linje är 10 kilometer, varefter en rutt byggs till denna punkt längs riktiga vägar. Troligtvis kommer det inte att vara rakt, så vi kommer att korta ner det till de angivna 10 kilometerna. Det finns många alternativ för sådana rutter - vi fick en riktig ruttgenerator!
Till en början ville jag dela upp kartan i områden som motsvarar grönområden: vallar, gårdar, gator, för att få den trevligaste vägen för en promenad och även generera musik i enlighet med dessa områden. Men att göra detta med Google Map API visade sig vara svårt (vi hade inte tid att lösa det här problemet). Det var dock möjligt att genomföra konstruktionen av en rutt genom specifika typer av platser (butik, park, bibliotek): om rutten gick runt alla de angivna platserna, men det önskade avståndet ännu inte har färdats, slutförs det till en användarspecificerat avstånd i en slumpmässig riktning. Google Map API låter dig också beräkna den beräknade restid, vilket hjälper dig att välja en spellista exakt för hela promenaden.
Som ett resultat, rutter efter startpunkt, avstånd och mellanliggande punkter; allt var förberett för att klassificera musik efter avsnitt av rutten, men på grund av tidsbrist beslöts det att lämna alternativet att välja en spellista helt enkelt som en extra gränssnittsgren. Således kunde användaren självständigt välja musik att lyssna på.
Det största problemet med att arbeta med musik var att inte veta var man kan få mp3-filer ifrån utan att användaren måste ha ett konto på någon tjänst. Det beslutades att begära musik från användaren (UserMusic-läge). Detta skapar ett nytt problem: inte alla har möjlighet att ladda ner spår. En lösning är att skapa ett arkiv med musik från användare (BotMusic-läge) – från det kan du generera musik oavsett tjänster.
Även om det inte var perfekt, slutförde vi uppgiften: vi slutade med en applikation som jag skulle vilja använda. Generellt sett är det här väldigt coolt: för tre dagar sedan hade du bara en idé och inte en enda tanke om exakt hur du skulle implementera den, men nu finns det en fungerande lösning. Det här var väldigt viktiga tre dagar för mig. Jag är inte längre rädd för att hitta på något som jag inte har tillräckligt med kunskap för att implementera, att vara teamleader var otroligt intressant och jag lärde känna de underbara killarna som gick med i mitt team bättre!
Liquid Democracy
Idéns författare
Stanislav Sychev
Lagkomposition
Stanislav Sychev – teamledare, databas
Nikolay Izyumov – bot-gränssnitt
Anton Ryabushev – backend
Inom olika grupper finns ofta behov av att fatta beslut eller rösta. Vanligtvis i sådana fall tillgriper de Men när gruppen blir stor kan det uppstå problem. Till exempel kanske en person i en grupp inte vill svara på frågor ofta eller svara på frågor om vissa ämnen. I stora grupper, för att undvika problem de tar till , när en separat grupp av "ställföreträdare" väljs bland alla människor, som befriar resten från bördan av val. Men att bli en sådan suppleant är ganska svårt, och personen som blir det kommer inte nödvändigtvis att vara ärlig och respektabel, som han verkade för väljarna.
För att lösa problemen med båda systemen föreslog Brian Ford konceptet . I ett sådant system är alla fria att välja rollen som en vanlig användare eller en delegat, helt enkelt genom att uttrycka sin önskan. Vem som helst kan rösta självständigt eller ge en röst till en delegat i en eller flera frågor. En delegat kan också avge sin röst. Dessutom, om delegaten inte längre passar väljaren, kan omröstningen återkallas när som helst.
Exempel på användandet av flytande demokrati finns i politiken, och vi ville implementera en liknande idé för vardagsbruk inom alla typer av grupper av människor. Vid nästa DevDays hackathon bestämde vi oss för att skriva en Telegram-bot för att rösta enligt principerna för flytande demokrati. Samtidigt ville jag undvika ett vanligt problem med sådana bots - att täppa till den allmänna chatten med meddelanden från boten. Lösningen är att få in så mycket funktionalitet som möjligt i ett personligt samtal.
För att skapa denna bot använde vi . En PostgreSQL-databas valdes för att lagra historiken för omröstningar och delegationer. För att kommunicera med boten installerades en Flask-server. Vi valde dessa tekniker för att... vi hade redan erfarenhet av att interagera med dem under våra masterstudier. Arbetet med de tre komponenterna i projektet – databasen, servern och boten – distribuerades framgångsrikt bland teammedlemmarna.
Naturligtvis är tre dagar en kort tid, så under hackathonet implementerade vi idén till prototypnivå. Som ett resultat skapade vi en bot som endast skriver information om öppnandet av röstningen och dess anonyma resultat till den allmänna chatten. Möjligheten att rösta och skapa en omröstning implementeras genom personlig korrespondens med boten. För att rösta, ange ett kommando som visar en lista över frågor som kräver direkt uppmärksamhet. I personlig korrespondens kan du se listan över delegater och deras tidigare röster, och även ge dem din röst i något av ämnena.
.
Det var intressant att jobba med projektet, vi stannade på universitetet till midnatt.Vi tycker att det här är ett bra sätt att ta en paus från studierna, även om det är väldigt ansträngande. Det var en trevlig upplevelse att arbeta i ett sammansvetsat team.
PS. Anmälan till masterprogram för nästa läsår är redan nu . Gå med nu!
Källa: www.habr.com