Recentemente nós sobre o programa de máster corporativo de JetBrains e ITMO University “Desenvolvemento de software / Enxeñaría de software”. Convidamos a todos os interesados a unha xornada de portas abertas o luns 29 de abril. Falarémosche das vantaxes do noso máster, que bonificacións ofrecemos aos estudantes e que demandamos a cambio. Ademais, responderemos definitivamente ás preguntas dos nosos convidados.
A xornada de portas abertas celebrarase na oficina de JetBrains no Times Business Center, onde estudan os nosos alumnos de máster. Comeza ás 17:00 h. Podes coñecer todos os detalles e rexistrarte no evento na páxina web . Ven e non te arrepentirás!
Un dos compoñentes principais do programa é a práctica. Os estudantes teñen moito: tarefas semanais, proxectos semestrales e hackathons. Grazas á completa inmersión en metodoloxías e tecnoloxías de desenvolvemento modernas durante os seus estudos, os titulados intégranse rapidamente nos procesos de traballo das grandes empresas informáticas.
Neste post queremos falar con máis detalle dos hackathons de DevDays, que teñen lugar cada seis meses. As regras son sinxelas: reúnense equipos de 3-4 persoas e durante tres días os alumnos dan vida ás súas propias ideas. Que pode vir disto? Le a primeira parte das historias sobre os proxectos de hackathon deste semestre dos propios estudantes :)
Diario con recomendacións de películas
Autor da idea
Iván Ilchuk
Estrutura de mando
Ivan Ilchuk: análise da trama da película, servidor
Vladislav Korablinov - desenvolvemento de modelos para comparar a proximidade dunha entrada de diario e a trama dunha película
Dmitry Valchuk - IU
Nikita Vinokurov – IU, deseño
O obxectivo do noso proxecto era escribir unha aplicación de escritorio: un diario que recomendase películas ao usuario en función das entradas nel.
Esta idea xurdiume cando estaba de camiño á universidade e pensando nos meus problemas. "Calquera que sexa o problema ao que se enfronte unha persoa, algún escritor clásico xa escribiu sobre iso", pensei. "E xa que alguén o escribiu, significa que alguén xa o filmou". Entón, o desexo de ver unha película sobre unha persoa co mesmo tormento mental apareceu naturalmente.
Obviamente, hai unha gran variedade de diarios e servizos de recomendación separados (pero normalmente as recomendacións baséanse no que lle gustaba previamente á persoa). En principio, este proxecto ten algo en común coa busca dunha película por puntos clave, pero aínda así, en primeiro lugar, a nosa aplicación ofrece a funcionalidade dun diario.
Como implementamos isto? Cando preme o botón máxico, o diario envía unha entrada ao servidor, onde se selecciona a película en función da descrición tomada da Wikipedia. O noso frontend fíxose en Electron (usámolo, non o sitio web, porque inicialmente decidimos almacenar os datos do usuario non no servidor, senón localmente no ordenador), e o servidor e o propio sistema de recomendación fixéronse en Python: os TF foron obtidos a partir das descricións -vectores IDF que foron comparados pola proximidade ao vector de entrada do diario.
Un membro do equipo traballou só no modelo, o outro traballou enteiramente no front-end (inicialmente xunto cun terceiro membro, que máis tarde pasou á proba). Dediqueime a analizar as tramas de películas da Wikipedia e do servidor.
Paso a paso achegámonos ao resultado, superando unha serie de problemas, comezando polo feito de que o modelo inicialmente requiría moita memoria RAM, rematando coa dificultade de transferir datos ao servidor.
Agora, para buscar unha película para a noite, non fai falla moito esforzo: o resultado do noso traballo de tres días é unha aplicación de escritorio e un servidor, aos que o usuario accede a través de https, recibindo como resposta unha selección de 5 películas con unha breve descrición e un cartel.
As miñas impresións sobre o proxecto son moi positivas: o traballo foi engaiolante desde primeira hora da mañá ata ben entrada a noite, e a aplicación resultante produce periodicamente resultados extremadamente divertidos ao estilo de "Sleepless Night" para unha entrada do diario sobre os deberes na universidade ou unha película. sobre o primeiro día de clase para unha historia sobre o primeiro día no departamento.
Pódense atopar ligazóns relevantes, instaladores, etc .
Xerador de rutas
Autor da idea
Artemyeva Irina
Estrutura de mando
Artemyeva Irina: líder do equipo, bucle principal
Gordeeva Lyudmila - música
Platonov Vladislav – rutas
Gústame moito andar pola cidade: mirar edificios, persoas, pensar na historia. Pero, aínda que cambie de lugar de residencia, tarde ou cedo atópome co problema de elixir unha ruta: teño rematado todas as que se me ocorren. Así xurdiu a idea de automatizar a xeración de rutas: indicas o punto de partida e a lonxitude da ruta, e o programa dáche unha opción. Os paseos poden ser longos, polo que un desenvolvemento lóxico da idea parece estar engadindo a posibilidade de indicar puntos intermedios para unha "parada", onde poderías merendar e descansar. Outra rama do desenvolvemento foi a música. Camiñar á música sempre é máis divertido, polo que sería xenial engadir a posibilidade de seleccionar unha lista de reprodución en función dunha ruta xerada.
Non foi posible atopar tales solucións entre as aplicacións existentes. Os análogos máis próximos son os planificadores de rutas: Google Maps, 2GIS, etc.
O máis cómodo é ter unha aplicación deste tipo no teu teléfono, polo que usar Telegram era unha boa opción. Permíteche mostrar mapas e reproducir música, e podes controlar todo isto escribindo un bot. O traballo principal cos mapas realizouse mediante a API de Google Maps. Python facilita a combinación de ambas tecnoloxías.
Había tres persoas no equipo, polo que a tarefa dividiuse en dúas subtarefas non solapadas (traballar con mapas e traballar con música) para que os rapaces puidesen traballar de forma independente, e eu encargueime de combinar os resultados.
Ningún de nós traballara nunca coa API de Google Maps nin cos robots escritos de Telegram, polo que o principal problema era o tempo que se dedicaba a implementar o proxecto: entender algo sempre leva máis tempo que facer algo que se coñece ben. Tamén foi difícil escoller a API do bot de Telegram: debido ao bloqueo, non funcionan todas e tiven que loitar para configurar todo.
Cabe mencionar por separado como se solucionou o problema da xeración de rutas. É doado construír unha ruta entre dúas localizacións, pero que lle podes ofrecer ao usuario se só se coñece a lonxitude da ruta? Deixa que o usuario queira camiñar 10 quilómetros. Selecciónase un punto nunha dirección arbitraria, a distancia á que en liña recta é de 10 quilómetros, despois de que se constrúe unha ruta ata este punto por estradas reais. O máis probable é que non sexa recto, polo que acurtarémolo ata os 10 quilómetros especificados. Hai moitas opcións para este tipo de rutas: temos un verdadeiro xerador de rutas!
Nun primeiro momento, quería segmentar o mapa en zonas correspondentes a zonas verdes: terrapléns, patios, rúas, para conseguir o percorrido máis agradable para o paseo, e tamén xerar música acorde a estas zonas. Pero facelo usando a API de Google Maps resultou difícil (non tivemos tempo para resolver este problema). Non obstante, foi posible implementar a construción dunha ruta a través de tipos específicos de localizacións (tenda, parque, biblioteca): se a ruta percorreu todos os lugares especificados, pero aínda non se percorreu a distancia desexada, complétase ata un distancia especificada polo usuario nunha dirección aleatoria. A API de Google Maps tamén che permite calcular o tempo estimado da viaxe, o que che axuda a escoller unha lista de reprodución exactamente para toda a camiñada.
Como resultado, rutas por punto de partida, distancia e puntos intermedios; todo estaba preparado para clasificar a música segundo tramos do percorrido, pero por falta de tempo decidiuse deixar a opción de seleccionar unha lista de reprodución simplemente como rama de IU adicional. Así, o usuario puido escoller de forma independente a música para escoitar.
O principal problema de traballar con música era non saber de onde obter ficheiros mp3 sen esixir que o usuario teña unha conta en ningún servizo. Decidiuse solicitar música ao usuario (modo UserMusic). Isto xera un novo problema: non todos teñen a posibilidade de descargar pistas. Unha solución é crear un repositorio con música dos usuarios (modo BotMusic): a partir del pode xerar música independentemente dos servizos.
Aínda que non era perfecto, completamos a tarefa: acabamos cunha aplicación que me gustaría usar. En xeral, isto é moi chulo: hai tres días só tiñas unha idea e nin un só pensamento sobre como implementala exactamente, pero agora hai unha solución que funciona. Foron tres días moi importantes para min. Xa non teño medo de inventar algo que non teño coñecementos suficientes para implementar, ser un líder de equipo foi incriblemente interesante e coñecín aos mozos marabillosos que se uniron ao meu equipo. mellor!
Democracia líquida
Autor da idea
Stanislav Sychev
Estrutura de mando
Stanislav Sychev – xefe de equipo, base de datos
Nikolay Izyumov - interface bot
Anton Ryabushev - backend
Dentro dos distintos grupos, moitas veces hai que tomar unha decisión ou votar. Normalmente, nestes casos recorren , porén, cando o grupo se fai grande, poden xurdir problemas. Por exemplo, é posible que unha persoa nun grupo non queira responder preguntas frecuentemente ou responder preguntas sobre determinados temas. En grupos grandes, para evitar problemas aos que recorren , cando se elixe entre todas as persoas un grupo separado de “deputados”, que liberan ao resto da carga da elección. Pero é bastante difícil converterse nun deputado así, e a persoa que se converta non será necesariamente honesta e respectable, como lles parecía aos votantes.
Para resolver os problemas de ambos sistemas, Brian Ford propuxo o concepto . Neste sistema, todos son libres de elixir o rol dun usuario habitual ou dun delegado, simplemente expresando o seu desexo. Calquera persoa pode votar de forma independente ou darlle o voto a un delegado sobre unha ou varias cuestións. Un delegado tamén pode emitir o seu voto. Ademais, se o delegado xa non lle convén ao elector, o voto poderá ser retirado en calquera momento.
Exemplos do uso da democracia líquida atópanse na política, e queriamos implementar unha idea semellante para o uso cotián dentro de todo tipo de grupos de persoas. No próximo hackathon de DevDays, decidimos escribir un bot de Telegram para votar segundo os principios da democracia líquida. Ao mesmo tempo, quería evitar un problema común con tales bots: obstruír o chat xeral con mensaxes do bot. A solución é aportar a maior funcionalidade posible nunha conversa persoal.
Para crear este bot usamos . Elixiuse unha base de datos PostgreSQL para almacenar o historial de votacións e delegacións. Para comunicarse co bot, instalouse un servidor Flask. Escollemos estas tecnoloxías porque... xa tiñamos experiencia interactuando con eles durante os nosos estudos de máster. O traballo sobre os tres compoñentes do proxecto (a base de datos, o servidor e o bot) distribuíuse con éxito entre os membros do equipo.
Por suposto, tres días son pouco tempo, polo que durante o hackathon implementamos a idea ata o nivel de prototipo. Como resultado, creamos un bot que escribe no chat xeral só información sobre a apertura da votación e os seus resultados anónimos. A posibilidade de votar e crear unha enquisa implícase a través da correspondencia persoal co bot. Para votar, introduza un comando que mostre unha lista de problemas que requiren atención directa. Na correspondencia persoal, podes ver a lista de delegados e as súas votacións anteriores, e tamén darlles o teu voto sobre algún dos temas.
.
Foi interesante traballar no proxecto, estivemos na universidade ata as doce da noite.Pensamos que esta é unha boa forma de facer un descanso dos estudos, aínda que é moi esgotador. Foi unha experiencia agradable traballar nun equipo unido.
PD. Xa está a matrícula para os programas de máster para o vindeiro curso . Unirse agora!
Fonte: www.habr.com