DevDays'19 Hackathon (Part 1): Diary with Recommendations, Walk Generator and Liquid Democracy
Recently, we talked about the corporate master program of JetBrains and ITMO University “Software Development / Software Engineering”. We invite everyone interested in the open day on Monday, April 29th. We will tell you about the advantages of our magistracy, what bonuses we offer to students and what we demand in return. In addition, we will answer the questions of our guests.
Open Day will be held at the JetBrains office in the Times, where students of our magistracy study. Beginning at 17:00. Learn all the details and register on the event at mse.itmo.ru. Come and you will not regret!
One of the main components of the training program is practice. Students have a lot of it: weekly homework, semester projects and hackathons. Due to complete immersion in modern methodologies and development technologies during their studies, graduates quickly join the work processes of large IT companies.
')
In this post we want to tell you more about the DevDays hackathons, which are held every six months. The rules are simple: teams of 3-4 people are assembled and within three days students implement their own ideas. What can come of it? Read the first part of the stories about the hackathon projects of this semester from the students themselves :)
Idea author
Ivan Ilchuk
Line-up
Ivan Ilchuk - parsing film plots, server
Vladislav Korablinov - development of models for comparing the proximity of the diary entry and the plot of the film
Dmitry Valchuk - UI
Nikita Vinokurov - UI, design
The goal of our project was to write a desktop application - a diary that would recommend films to the user based on the records in it.
This idea occurred to me when I went to the university and thought about my problems. “No matter what problem a person faces, some classic has already written about this,” I thought. “And if someone wrote, it means that someone already filmed”. ” So the desire to watch a movie about a person with the same mental torments appeared by itself.
Obviously, there is a wide variety of separate diaries and separate recommendation services (but usually the recommendations are based on what the person liked earlier). In principle, this project has something in common with the search for a movie by key points, but still, first of all, our application provides the functionality of a diary.
How did we implement it? When you press the magic button, the diary sends an entry to the server, where the movie is selected on the basis of the description taken from Wikipedia. Our frontend was made on Electron (we use it, not the site, because initially we decided to store user data not on the server, but locally on the computer), but the server and the recommender system itself - in Python: TF was obtained from descriptions -IDF vectors that were compared for proximity to a diary entry vector.
One team member worked only on the model, the other on the whole frontend (initially for a couple with a third participant, who later switched to testing). I was engaged in parsing the film with Wikipedia and the server.
Step by step, we approached the result, overcoming a number of problems, starting with the fact that the model initially required a lot of RAM, ending with the difficulty of transferring data to the server.
Now, in order to find a movie for the evening, it does not take a lot of effort: the result of our three-day work was the desktop application and the server that the user accesses via https, receiving in return a selection of 5 films with a brief description and a poster.
I have very positive impressions of the project: the work was exciting from early morning until late at night, and the resulting application periodically gives out extremely funny results in the “Sleepless Night” style on a diary entry about homework in the university or a film about the first school day on the first day story at the department.
Relevant links, installers and more can be found here .
Idea author
Artemyeva Irina
Line-up
Artemyeva Irina - timlid, main loop
Gordeeva Lyudmila - music
Platonov Vladislav - routes
I really like to walk around the city: to look at buildings, at people, to reflect on history. But, even changing my place of residence, sooner or later I will face the problem of choosing a route: everything I could think of was gone. So the idea was to automate the generation of routes: you specify the starting point and the length of the route, and the program gives you an option. Walking can be long, so the logical development of the idea seems to be adding the ability to indicate intermediate points for a “halt” where you could have a snack and rest. Another branch of development was music. Going to music is always more fun, so it would be great to add the ability to select a playlist for the generated route.
Among the existing applications such solutions could not be found. The closest analogues are any route planners: Google Maps, 2GIS, etc.
Such an application is most convenient to have on the phone, so using Telegram was a good option. It allows you to display maps and play music, and you can manage all of this by writing a bot. The main work with maps was made using the Google Map API. Easy to make friends with both technologies allows Python.
There were three people in the team, so the task was divided into two non-intersecting subtasks (working with maps and working with music) so that the guys could work independently and I took over the integration of the results.
None of us have ever worked with the Google Map API and have not written Telegram bots, so the main problem was the amount of time allotted for the project: it always takes more time to figure out something than to do what you know well. It was also difficult to choose the Telegram-bot API: because of the blocking, not everything works and I had to suffer in order to configure everything.
Separately, it should be said how the problem of generating routes was solved. It is easy to build a route between two locations, but what to offer the user if only the length of the route is known? Let the user want to go 10 kilometers. In an arbitrary direction, a point is chosen, the distance to which in a straight line is 10 kilometers, after which a route is constructed along real roads to this point. Most likely it will not be direct, therefore we shorten it to the given 10 kilometers. There are a lot of options for such routes - we got a real route generator!
Initially, I wanted to segment the map into areas corresponding to green areas: embankments, courtyards, streets, in order to get the most pleasant route for walking, as well as generate music in accordance with these areas. But it was not easy to do this using the Google Map API (they did not have time to solve this problem). However, it turned out to implement the construction of a route through specific types of locations (shop, park, library): if the route has bypassed all the specified places, but the desired distance has not yet been covered, it is completed to the user-specified distance in a random direction. Also, Google Map API allows you to calculate the estimated travel time, which helps to choose a playlist exactly for the entire walk.
As a result, it turned out to make the generation of routes by starting point, distance and intermediate points; everything was prepared for classifying music according to sections of the route, but due to lack of time it was decided to leave the possibility of selecting a playlist simply as an additional UI branch. Thus, the user was able to independently select music for listening.
The main problem of working with music was in ignorance, from where you can take mp3-files so as not to require the user to have an account on any service. It was decided to request music from the user (UserMusic mode). This creates a new problem: not everyone has the ability to download tracks. One solution is to create a repository with music from users (BotMusic mode) - you can generate music from it, regardless of the services.
Although not perfect, we coped with the task: it turned out an application that I would like to use. In general, it is very cool: three days ago you had only an idea and not a single thought how to implement it, but now there is a working solution. For me, it was a very important three days. I am no longer afraid to invent something for the implementation of which there is not enough knowledge, it was incredibly interesting to be a team leader, and I got to know better the great guys who went to my team!
Idea author
Stanislav Sychev
Line-up
Stanislav Sychev - timlid, database
Nikolai Izyumov - bot interface
Anton Ryabushev - backend
Within different groups, it is often necessary to make a decision or vote. Usually in such cases they resort to direct democracy , however, when the group becomes large, problems may arise. For example, a person from a group may not be willing to answer questions frequently or to answer questions on certain topics. In large groups, in order to avoid problems, representative democracy is resorted to when a separate group of “deputies” is chosen from all the people, who relieve the rest of the burden of choice. But to become such a deputy is quite difficult, and a person who has become one of them will not necessarily be honest and respectable, as he imagined to the voters.
To solve the problems of both systems, Brian Ford proposed the concept of liquid democracy . In such a system, everyone is free to choose the role of a regular user or delegate, simply expressing a desire. Anyone can vote on their own or cast their vote on one or more questions to a delegate. The delegate can also cast his vote. In this case, if the delegate has ceased to arrange the voter, the vote can be withdrawn at any time.
Examples of using liquid democracy are found in politics, and we wanted to implement a similar idea for everyday use within all kinds of groups of people. At the next DevDays hackathon, we decided to write a Telegram-bot for voting on the principles of liquid democracy. At the same time, I wanted to avoid the common problem of such bots - the common messages were blocked by the chat messages from the bot. The solution is to bring out as much functionality as possible in a personal conversation.
To create this bot, we used the Telegram API . For storing the history of polls and delegations, we chose the PostgreSQL database. To communicate with the bot database was raised Flask-server. We chose these technologies because we already had experience of interacting with them while studying in the magistracy. The work on the three components of the project - the database, the server and the bot - was successfully distributed among the team members.
Of course, three days is a short time, so during the hackathon we implemented the idea to the level of the prototype. As a result, we created a bot that writes to the general chat only information about the opening of the vote and its anonymous results. Opportunities to vote and create a vote are implemented through personal correspondence with the bot. For voting, a team is introduced that lists the issues that require direct attention. In personal correspondence, you can see the list of delegates and their previous votes, and also give them your vote on one of the topics.
Video with an example of work .
It was interesting to work on the project, we stayed at the university until midnight. It seems to us that this is a great way to take a break from studying, although it is very exhausting. There was a pleasant work experience in a close-knit team.
PS: Admission to the magistracy for the next academic year is already open . Join now!
Open Day will be held at the JetBrains office in the Times, where students of our magistracy study. Beginning at 17:00. Learn all the details and register on the event at mse.itmo.ru. Come and you will not regret!
One of the main components of the training program is practice. Students have a lot of it: weekly homework, semester projects and hackathons. Due to complete immersion in modern methodologies and development technologies during their studies, graduates quickly join the work processes of large IT companies.
')
In this post we want to tell you more about the DevDays hackathons, which are held every six months. The rules are simple: teams of 3-4 people are assembled and within three days students implement their own ideas. What can come of it? Read the first part of the stories about the hackathon projects of this semester from the students themselves :)
Movie diary with recommendations
Idea author
Ivan Ilchuk
Line-up
Ivan Ilchuk - parsing film plots, server
Vladislav Korablinov - development of models for comparing the proximity of the diary entry and the plot of the film
Dmitry Valchuk - UI
Nikita Vinokurov - UI, design
The goal of our project was to write a desktop application - a diary that would recommend films to the user based on the records in it.
This idea occurred to me when I went to the university and thought about my problems. “No matter what problem a person faces, some classic has already written about this,” I thought. “And if someone wrote, it means that someone already filmed”. ” So the desire to watch a movie about a person with the same mental torments appeared by itself.
Obviously, there is a wide variety of separate diaries and separate recommendation services (but usually the recommendations are based on what the person liked earlier). In principle, this project has something in common with the search for a movie by key points, but still, first of all, our application provides the functionality of a diary.
How did we implement it? When you press the magic button, the diary sends an entry to the server, where the movie is selected on the basis of the description taken from Wikipedia. Our frontend was made on Electron (we use it, not the site, because initially we decided to store user data not on the server, but locally on the computer), but the server and the recommender system itself - in Python: TF was obtained from descriptions -IDF vectors that were compared for proximity to a diary entry vector.
One team member worked only on the model, the other on the whole frontend (initially for a couple with a third participant, who later switched to testing). I was engaged in parsing the film with Wikipedia and the server.
Step by step, we approached the result, overcoming a number of problems, starting with the fact that the model initially required a lot of RAM, ending with the difficulty of transferring data to the server.
Now, in order to find a movie for the evening, it does not take a lot of effort: the result of our three-day work was the desktop application and the server that the user accesses via https, receiving in return a selection of 5 films with a brief description and a poster.
I have very positive impressions of the project: the work was exciting from early morning until late at night, and the resulting application periodically gives out extremely funny results in the “Sleepless Night” style on a diary entry about homework in the university or a film about the first school day on the first day story at the department.
Relevant links, installers and more can be found here .
Route generator
Idea author
Artemyeva Irina
Line-up
Artemyeva Irina - timlid, main loop
Gordeeva Lyudmila - music
Platonov Vladislav - routes
I really like to walk around the city: to look at buildings, at people, to reflect on history. But, even changing my place of residence, sooner or later I will face the problem of choosing a route: everything I could think of was gone. So the idea was to automate the generation of routes: you specify the starting point and the length of the route, and the program gives you an option. Walking can be long, so the logical development of the idea seems to be adding the ability to indicate intermediate points for a “halt” where you could have a snack and rest. Another branch of development was music. Going to music is always more fun, so it would be great to add the ability to select a playlist for the generated route.
Among the existing applications such solutions could not be found. The closest analogues are any route planners: Google Maps, 2GIS, etc.
Such an application is most convenient to have on the phone, so using Telegram was a good option. It allows you to display maps and play music, and you can manage all of this by writing a bot. The main work with maps was made using the Google Map API. Easy to make friends with both technologies allows Python.
There were three people in the team, so the task was divided into two non-intersecting subtasks (working with maps and working with music) so that the guys could work independently and I took over the integration of the results.
None of us have ever worked with the Google Map API and have not written Telegram bots, so the main problem was the amount of time allotted for the project: it always takes more time to figure out something than to do what you know well. It was also difficult to choose the Telegram-bot API: because of the blocking, not everything works and I had to suffer in order to configure everything.
Separately, it should be said how the problem of generating routes was solved. It is easy to build a route between two locations, but what to offer the user if only the length of the route is known? Let the user want to go 10 kilometers. In an arbitrary direction, a point is chosen, the distance to which in a straight line is 10 kilometers, after which a route is constructed along real roads to this point. Most likely it will not be direct, therefore we shorten it to the given 10 kilometers. There are a lot of options for such routes - we got a real route generator!
Initially, I wanted to segment the map into areas corresponding to green areas: embankments, courtyards, streets, in order to get the most pleasant route for walking, as well as generate music in accordance with these areas. But it was not easy to do this using the Google Map API (they did not have time to solve this problem). However, it turned out to implement the construction of a route through specific types of locations (shop, park, library): if the route has bypassed all the specified places, but the desired distance has not yet been covered, it is completed to the user-specified distance in a random direction. Also, Google Map API allows you to calculate the estimated travel time, which helps to choose a playlist exactly for the entire walk.
As a result, it turned out to make the generation of routes by starting point, distance and intermediate points; everything was prepared for classifying music according to sections of the route, but due to lack of time it was decided to leave the possibility of selecting a playlist simply as an additional UI branch. Thus, the user was able to independently select music for listening.
The main problem of working with music was in ignorance, from where you can take mp3-files so as not to require the user to have an account on any service. It was decided to request music from the user (UserMusic mode). This creates a new problem: not everyone has the ability to download tracks. One solution is to create a repository with music from users (BotMusic mode) - you can generate music from it, regardless of the services.
Although not perfect, we coped with the task: it turned out an application that I would like to use. In general, it is very cool: three days ago you had only an idea and not a single thought how to implement it, but now there is a working solution. For me, it was a very important three days. I am no longer afraid to invent something for the implementation of which there is not enough knowledge, it was incredibly interesting to be a team leader, and I got to know better the great guys who went to my team!
Liquid Democracy
Idea author
Stanislav Sychev
Line-up
Stanislav Sychev - timlid, database
Nikolai Izyumov - bot interface
Anton Ryabushev - backend
Within different groups, it is often necessary to make a decision or vote. Usually in such cases they resort to direct democracy , however, when the group becomes large, problems may arise. For example, a person from a group may not be willing to answer questions frequently or to answer questions on certain topics. In large groups, in order to avoid problems, representative democracy is resorted to when a separate group of “deputies” is chosen from all the people, who relieve the rest of the burden of choice. But to become such a deputy is quite difficult, and a person who has become one of them will not necessarily be honest and respectable, as he imagined to the voters.
To solve the problems of both systems, Brian Ford proposed the concept of liquid democracy . In such a system, everyone is free to choose the role of a regular user or delegate, simply expressing a desire. Anyone can vote on their own or cast their vote on one or more questions to a delegate. The delegate can also cast his vote. In this case, if the delegate has ceased to arrange the voter, the vote can be withdrawn at any time.
Examples of using liquid democracy are found in politics, and we wanted to implement a similar idea for everyday use within all kinds of groups of people. At the next DevDays hackathon, we decided to write a Telegram-bot for voting on the principles of liquid democracy. At the same time, I wanted to avoid the common problem of such bots - the common messages were blocked by the chat messages from the bot. The solution is to bring out as much functionality as possible in a personal conversation.
To create this bot, we used the Telegram API . For storing the history of polls and delegations, we chose the PostgreSQL database. To communicate with the bot database was raised Flask-server. We chose these technologies because we already had experience of interacting with them while studying in the magistracy. The work on the three components of the project - the database, the server and the bot - was successfully distributed among the team members.
Of course, three days is a short time, so during the hackathon we implemented the idea to the level of the prototype. As a result, we created a bot that writes to the general chat only information about the opening of the vote and its anonymous results. Opportunities to vote and create a vote are implemented through personal correspondence with the bot. For voting, a team is introduced that lists the issues that require direct attention. In personal correspondence, you can see the list of delegates and their previous votes, and also give them your vote on one of the topics.
Video with an example of work .
It was interesting to work on the project, we stayed at the university until midnight. It seems to us that this is a great way to take a break from studying, although it is very exhausting. There was a pleasant work experience in a close-knit team.
PS: Admission to the magistracy for the next academic year is already open . Join now!
Source: https://habr.com/ru/post/449042/
All Articles