Recently we about the JetBrains and ITMO University Corporate Master's Program in Software Engineering. We invite everyone interested to the open day on Monday, April 29th. We will talk about the benefits of our master's program, about what bonuses we offer students and what we demand in return. In addition, we will definitely answer the questions of our guests.
The Open Doors Day will be held at the JetBrains office in the Times business center, where our master's students study. Start at 17:00. For more details and to register for the event, please visit the website. . Come and you won't regret it!
One of the main components of training on the program is practice. Students have a lot of it: weekly homework, semester projects and hackathons. Thanks to full immersion in modern development methodologies and technologies during their studies, graduates quickly join the workflows of large IT companies.
In this post, we want to tell you more about the DevDays hackathons, which take place every six months. The rules are simple: teams of 3-4 people gather and within three days students bring their own ideas to life. What can come of this? Read the first part of stories about this semester hackathon projects from the students themselves π
Movie recommendation diary
The author of idea
Ivan Ilchuk
Line-up
Ivan Ilchuk - parsing movie plots, server
Vladislav Korablinov - development of models for comparing the proximity of a diary entry and a film plot
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 entries in it.
This idea came to my mind when I was driving to the university and thinking about my problems. βWhatever problem a person faces, some classic has already written about it,β I thought. βAnd since someone wrote it, it means that someone has already filmed it.β So the desire to watch a film about a person with the same mental anguish 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 previously liked). In principle, this project has something in common with searching for a movie by key moments, but still, first of all, our application provides the functionality of a diary.
How did we implement it? When the magic button is pressed, the diary sends an entry to the server, where the movie is selected based on the description taken from Wikipedia. Our frontend was made on Electron (we use it, not the website, because we initially decided to store user data not on the server, but locally on the computer), and the server and the recommender system itself were made in Python: TF was obtained from the descriptions -IDF vectors that were compared for proximity with the diary entry vector.
One member of the team was engaged only in the model, the other in the entire front-end (initially, together with a third member, who later switched to testing). I was engaged in parsing the plots of the film from 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, it doesnβt take much effort to find a movie for the evening: the result of our three-day work is a desktop application and a server that the user accesses via https, receiving in response a selection of 5 films with a brief description and a poster.
My impressions of the project are very positive: the work was captivating from early morning until late at night, and the resulting application periodically produces extremely funny results in the style of "Sleepless Night" for a diary entry about homework at the university or a film about the first day of school for a story about the first day at the department.
Relevant links, installers and more can be found .
route generator
The author of idea
Artemyeva Irina
Line-up
Artemyeva Irina β team leader, main loop
Gordeeva Ludmila - music
Platonov Vladislav - routes
I really like walking around the city: looking at buildings, at people, thinking about history. But, even when changing my place of residence, sooner or later I face the problem of choosing a route: I passed everything that I could think of. So the idea came up to automate the generation of routes: you specify the starting point and the length of the route, and the program issues a variant. Walks can be long, so it seems like a logical development of the idea to add the ability to specify intermediate points for a βhaltβ, where one could have a bite to eat and relax. Music has become another branch of development. Walking to the music is always more fun, so it would be great to add the ability to select a playlist along a generated route.
It was not possible to find such solutions among the existing applications. The closest analogues are any route planners: Google Maps, 2GIS, etc.
It is most convenient to have such an application on the phone, so using Telegram was a good option. It allows you to display maps and play music, and you can manage all this by writing a bot. The main work with maps was carried out using the Google Map API. Python makes it easy to make friends between both technologies.
There were three people in the team, so the task was divided into two non-overlapping subtasks (working with maps and working with music), so that the guys could work independently, and I took over the merging of the results.
None of us have ever worked with the Google Map API or written Telegram bots, so the main problem was the amount of time allotted for the project implementation: understanding something always takes more time than doing what you know well. It was also difficult to choose the Telegram bot API: due to the blocking, not everyone works and I had to suffer to set everything up.
Separately, it is worth mentioning how the problem of generating routes was solved. It's 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 walk 10 kilometers. In an arbitrary direction, a point is selected, the distance to which in a straight line is 10 kilometers, after which a route is built to this point along real roads. Most likely it will not be straight, so we will shorten it to the specified 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 sections corresponding to green areas: embankments, courtyards, streets, in order to get the most pleasant route for walking, and also generate music in accordance with these sections. But it was not easy to do this using the Google Map API (they did not manage 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 distance specified by the user in a random direction. The Google Map API also allows you to calculate the estimated travel time, which helps you choose the exact playlist for the entire trip.
Eventually routes by starting point, distance and intermediate points; everything was prepared for classifying music according to route sections, but due to lack of time, it was decided to leave the ability to select a playlist simply as an additional UI branch. Thus, the user got the opportunity to independently choose the music to listen to.
The main problem with working with music was not knowing where to get mp3 files from without requiring 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 of the solutions is to create a repository with music from users (BotMusic mode) - you can generate music from it independently of services.
Although not perfect, we coped with the task: we got an application that I would like to use. In general, this is very cool: three days ago you had only an idea and not a single thought on how to implement it, and now there is a working solution. These were very important three days for me. I am no longer afraid to come up with something that I donβt have enough knowledge to implement, it was incredibly interesting to be a team leader, and I got to know the wonderful guys who joined my team better!
Liquid Democracy
The author of idea
Stanislav Sychev
Line-up
Stanislav Sychev - team leader, database
Nikolay Izyumov - bot interface
Anton Ryabushev - backend
Within various groups, there is often a need to make a decision or vote. Usually in such cases one resorts to however, when the group becomes large, problems can arise. So, for example, a person in a group may not want to answer questions frequently or answer questions about certain topics. In large groups, to avoid problems, they resort to when a separate group of "deputies" is elected from all people, who free the rest from the burden of choice. But it is quite difficult to become such a deputy, and the person who has become one will not necessarily be honest and respectable, as he seemed to the voters.
To solve the problems of both systems, Brian Ford proposed the concept . In such a system, everyone is free to choose the role of a regular user or delegate, simply by expressing a desire. Any person can vote independently or cast their vote to a delegate on one or more issues. A delegate may also cast his or her vote. At the same time, if the delegate ceased to suit the voter, the vote can be withdrawn at any time.
There are examples of the use of liquid democracy in politics, and we wanted to implement a similar idea for everyday use within all sorts 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 a common problem of such bots - clogging the general chat with messages from the bot. The solution is to bring as much functionality as possible into a personal conversation.
To create this bot, we used . The PostgreSQL database was chosen to store the history of voting and delegations. To communicate with the database, the bot was raised Flask-server. We chose these technologies because we already had experience of interacting with them while studying at the magistracy. 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 prototype level. As a result, we created a bot that writes to the general chat only information about the opening of voting and its anonymous results. The ability to vote and create a vote is implemented through personal correspondence with the bot. For voting, a command is entered that displays a list of issues that require direct attention. In personal correspondence, you can see the list of delegates and their previous votes, as well as give them your vote on one of the topics.
.
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 experience of working in a close-knit team.
PS. Admission to the master's program for the next academic year is already . Join now!
Source: www.habr.com