
Kodim – pizza
Hi, Habr. We spontaneously held the first internal hackathon. I decided to share with you my pains and conclusions about preparing for it in 2 weeks, as well as the projects that turned out.

I'll start with a little story.
The beginning of April. The first hackathon MskDotNet Community is held in our office. The battle for Tatooine is in full swing, in our galaxy this time. Saturday. 20 teams. Pizza. Everything is very sincere ( proofs ). Inflatable R2-D2 looms around the hall. Teams write the most correct algorithms to pass the most dangerous race on the map. We shift the launch of the first races. Cookies and coffee save. The organizers and I expected that on Saturday, many would leave after dinner. But no. 12 hours of coding behind. The final. Something falls off, something does not start. But everyone is happy. Our team wins. We are doubly happy.
I share my joy in Slack and the idea comes to my head: "We need to make our own hackathon." I am writing to our service station Sasha. Silence.
Morning. I drink coffee in the office. I see Sasha coming from behind. “Lisa, that's great! We have an important date on April 21. Let's do it! ”WTF !? So fast? A? What? I need to fly to Syktyvkar for an internship in mid-April. Yes, and to hell with him! Come on.
Remains 2 weeks. I have never been the sole organizer of a hackathon. Let it be internal. I read articles on this topic. Tin. It takes a few months. Need a few people. It is necessary to think over the merch, prizes, conditions, schedule, interest, understand the goal, budgets. Or maybe even figure out the meaning of life. I definitely won’t have time. And while you read and prepared, a week has passed. It's time to score on articles and start doing something.
Why April 21? This day is significant for us. Exactly a year ago, on April 21, we fell under load during the first weekend after the start of the Federal Advertising Campaign. The next day, Sunday, our team was at work from 8 in the morning. Then we created a sundayhackathon board in Trello and began a shift week of 12 hours a day. The situation was so critical that we had no time even to eat and we were fed by guys from other teams.

You can read a more detailed story on the page of Fedor Ovchinnikov (our CEO). Since then, we have changed a lot, but now we definitely will not forget the date.
This year, we decided that this event should be immortalized in the memory of descendants, and in the best traditions we organized the first internal hackathon in the history of Dodo, which lasted 10 hours.
Disclaimer: all the descriptions were written by the guys themselves, so the authorship of the text is not mine.
Dima Kochnev, Sasha Andronov (@alexandronov)
They wanted to make a neural network that would determine what kind of pizza in the photo without any knowledge. As a result, they made a very simple and toy one - it recognizes 10 pizzas, figured out how everything works, how much it is possible in a day (~ 10 hours).

In particular, we realized that the industry has reached the point where an ordinary developer can take ready-made libraries, read documentation and train his neural network without deep knowledge of the subject. And it will work well enough to solve real problems.
Tools that used:
We had 11,000 photos, but almost 3/4 of them turned out to be rubbish, and the remaining ones showed different, inappropriate angles. As a result, we took the finished model (which just knows how to find pizza) and with its help we separated the most trash. Further, in the name of the photo was the name of pizza - that’s how we put them in folders, but it turned out that the names did not coincide with reality and we had to clean it up with our hands. As a result, about 500-600 photos remained, it is clear that this is an insignificant amount, but nevertheless, this was enough to separate 10 pizzas from one another.
To train the grid, they took the cheapest virtual machine in Azure on the NVIDIA Tesla K80. It was trained in 100 eras, but it was clear that the network was oversaturated after 50 eras, due to the fact that there was a small dataset.
Actually - the whole problem is the lack of good data.

We may have mixed up a little in terms, but we must bear in mind that we generally do not have experience in working with all these matters.
Misha Kumachev ( Ceridan ), Zhenya Bikkinin, Zhenya Vasiliev
We have assembled a prototype console application for geeks, thanks to which you can order pizza through the terminal or command line, or even integrate it into the deploy pipeline and deliver pizza to the office upon successful release.

The work was divided into several parts: we figured out how our API for mobile applications works , assembled our own CLI using oclifand set up the publication of our package. The last task was associated with several unpleasant minutes towards the end of the hackathon. Everything worked for us locally and even the old published versions of the package worked, but the new ones (in which more cool features and emoticons were added) refused to work. We spent 40 minutes to figure out what went wrong, but in the end it all worked magically).
Our maximum hackathon program was a real pizza order to the office through our CLI. We drove everything a dozen times at the test bench, but my hands still shook when I scored teams at the prod.

As a result - we still did it!

Anton Bruzhmelev (author), Vanya Zverev, Gleb Lesnikov ( entropy ), Andrey Sarafanov
We took the idea of “Application for the courier”.

In the morning at the hackathon, Gleb was drawn into his super-promising project. They quickly laid out a plan of what needs to be done.

They made a mistake when, in accordance with the project template, they tried to make communication not through HTTP, but through GRPC, since no one knew how to build a GRPC client for JavaScript. As a result, having spent about an hour and a half on this, they abandoned this idea. Because of this, the guys and on the back began to redo the finished server from GRPC to WebApi. After half an hour, finally, we were able to configure the application’s communication with the backend, lo and behold. But at the same time, Gleb almost finished off the deployment in k8s and plus auto-deed by committing to the master. :)
As the repository, we chose MySQL so as not to risk even the base (there were thoughts about CosmosDb).

Eventually:
Roma Bukin, Gosha Polevoy ( georgepolevoy ), Artyom Trofimushkin
We wanted to implement the OpenID Connect provider, as we currently use our own authentication protocol, and this creates a number of difficulties: custom client libraries, inconvenient work from external partners, and possibly problems with security (after all, OAuth2.0 and OpenID Connect in the reference implementation can be considered safe, but as for our solution, I'm not sure).

We made a separate service emulating a personal data storage service in order to create a small model of the Country-Agnostic authentication provider, which would go to a separate service for personal data (this would make it possible in the future to have one service with which you could log in with your account record in any country, and at the same time comply with GDPR and other Federal Laws). We did this part, like the provider, and successfully linked them to each other. Next, it was necessary to make an API that would be protected by tokens issued by the provider, support their introspection through the provider, and send protected data if the request satisfies authorization policies (we verify that the user is authenticated using the Bearer scheme, its token contains a certain scope + the user himself has permissions, allowing the call to be made). This part has also been completed. The last component was a JavaScript client that would be issued a token, with which it would call a secure API. We did not manage to make this part. That is, the entire functional part was ready, but the front-end part was not ready to demonstrate the operability of the entire system.
Dima Afonchenko, Sasha Konovalov
We made a mini-toy on a little one where frisky hands put sausage on pizza. If you incorrectly threw a sausage, the sad message “Rejected” appears on the screen, and if the whole sausage is thrown correctly, a random fact about pizza appears.

They wanted to make the second level with a spread of tomatoes, but did not have time.

Before the hackathon, we talked with the guys and I asked what prize they would like to receive if they win. It turned out that the road to food would be the most valuable prize.

Therefore, soon expect from us the announcement of the game with handles topping pepperoni on pizza.

The boring part for those interested in marketing
I'll start with a little story.
The beginning of April. The first hackathon MskDotNet Community is held in our office. The battle for Tatooine is in full swing, in our galaxy this time. Saturday. 20 teams. Pizza. Everything is very sincere ( proofs ). Inflatable R2-D2 looms around the hall. Teams write the most correct algorithms to pass the most dangerous race on the map. We shift the launch of the first races. Cookies and coffee save. The organizers and I expected that on Saturday, many would leave after dinner. But no. 12 hours of coding behind. The final. Something falls off, something does not start. But everyone is happy. Our team wins. We are doubly happy.
I share my joy in Slack and the idea comes to my head: "We need to make our own hackathon." I am writing to our service station Sasha. Silence.
Morning. I drink coffee in the office. I see Sasha coming from behind. “Lisa, that's great! We have an important date on April 21. Let's do it! ”WTF !? So fast? A? What? I need to fly to Syktyvkar for an internship in mid-April. Yes, and to hell with him! Come on.
Remains 2 weeks. I have never been the sole organizer of a hackathon. Let it be internal. I read articles on this topic. Tin. It takes a few months. Need a few people. It is necessary to think over the merch, prizes, conditions, schedule, interest, understand the goal, budgets. Or maybe even figure out the meaning of life. I definitely won’t have time. And while you read and prepared, a week has passed. It's time to score on articles and start doing something.
Catch our 1-week internal hackathon checklist
- Plan : sit down quietly and write a list of what needs to be done for the hackathon. 30 minutes .
- Objective : participants themselves propose and choose the projects that they want to create in Google Sheets. Background task, 2 hours .
- Schedule : on the knee you write a short breakdown in time taking into account 3 breaks and the final. 20 minutes .
- Teams : you publish a message about the hackathon with the schedule from the service station in IT channels in Slack / mail / etc and create a separate channel for the hackathon. In it, everyone is divided into teams, and undecided do it in the first 5 minutes of the hackathon. Background task, 2 hours .
- Pluses : you come up with a merch with two developers, you give the designer a render, you get ready. Background task, 3 days .
- Hackathon : you come to the office, coordinate everything at the beginning, go about your business, read Reddit, inform each break about fresh pizza, take a picture of the sunset, announce the final, vote together and choose the winner. 1 day .
- Under the asterisk : of course, you constantly think that everything went well. Of course, not everyone will see your message and it’s better to talk to some personally. Of course, if someone will help you, everything will become 2 times easier (the wonderful Alena helped me).
The less boring part about the hackathon date
Why April 21? This day is significant for us. Exactly a year ago, on April 21, we fell under load during the first weekend after the start of the Federal Advertising Campaign. The next day, Sunday, our team was at work from 8 in the morning. Then we created a sundayhackathon board in Trello and began a shift week of 12 hours a day. The situation was so critical that we had no time even to eat and we were fed by guys from other teams.

You can read a more detailed story on the page of Fedor Ovchinnikov (our CEO). Since then, we have changed a lot, but now we definitely will not forget the date.
This year, we decided that this event should be immortalized in the memory of descendants, and in the best traditions we organized the first internal hackathon in the history of Dodo, which lasted 10 hours.
The most boring part about hackathon projects
Disclaimer: all the descriptions were written by the guys themselves, so the authorship of the text is not mine.
Oleg Lörning (cars lörning)
Dima Kochnev, Sasha Andronov (@alexandronov)
They wanted to make a neural network that would determine what kind of pizza in the photo without any knowledge. As a result, they made a very simple and toy one - it recognizes 10 pizzas, figured out how everything works, how much it is possible in a day (~ 10 hours).

In particular, we realized that the industry has reached the point where an ordinary developer can take ready-made libraries, read documentation and train his neural network without deep knowledge of the subject. And it will work well enough to solve real problems.
Tools that used:
- imageai is a convenient and simple library for working with machine learning and computer vision.
- Two models have tried - ResNet50, Yolo.
- The code was written, of course, in python.
We had 11,000 photos, but almost 3/4 of them turned out to be rubbish, and the remaining ones showed different, inappropriate angles. As a result, we took the finished model (which just knows how to find pizza) and with its help we separated the most trash. Further, in the name of the photo was the name of pizza - that’s how we put them in folders, but it turned out that the names did not coincide with reality and we had to clean it up with our hands. As a result, about 500-600 photos remained, it is clear that this is an insignificant amount, but nevertheless, this was enough to separate 10 pizzas from one another.
To train the grid, they took the cheapest virtual machine in Azure on the NVIDIA Tesla K80. It was trained in 100 eras, but it was clear that the network was oversaturated after 50 eras, due to the fact that there was a small dataset.
Actually - the whole problem is the lack of good data.

We may have mixed up a little in terms, but we must bear in mind that we generally do not have experience in working with all these matters.
GUI for NOOBS (console for ordering pizza)
Misha Kumachev ( Ceridan ), Zhenya Bikkinin, Zhenya Vasiliev
We have assembled a prototype console application for geeks, thanks to which you can order pizza through the terminal or command line, or even integrate it into the deploy pipeline and deliver pizza to the office upon successful release.

The work was divided into several parts: we figured out how our API for mobile applications works , assembled our own CLI using oclifand set up the publication of our package. The last task was associated with several unpleasant minutes towards the end of the hackathon. Everything worked for us locally and even the old published versions of the package worked, but the new ones (in which more cool features and emoticons were added) refused to work. We spent 40 minutes to figure out what went wrong, but in the end it all worked magically).
Our maximum hackathon program was a real pizza order to the office through our CLI. We drove everything a dozen times at the test bench, but my hands still shook when I scored teams at the prod.

As a result - we still did it!

Courier go
Anton Bruzhmelev (author), Vanya Zverev, Gleb Lesnikov ( entropy ), Andrey Sarafanov
We took the idea of “Application for the courier”.
Background about the preparation.
Initially, I figured out, but what features can be in the application? Something like this appeared:
Plus a couple of alternative scenarios:
The sense of promise and need for this project certainly charged.
The next day, we went with the team for lunch and discussed what the minimal functionality of the application would look like.
As a result, the following list of what had to be done on the hackathon was formed:
The main work, as I saw it, was to create the backend, the application itself (after discussions, we chose ReactNative for developing the application, or rather, tying it over - expo.io , which allows you to not write native code at all). In terms of the backend, there was initially hope for Vanya Zverev, as an experienced in working with our service template and k8s (what kind of work he took on himself). ReactNative took me and Andrei Sarafanov.
I decided to try to immediately create a working repository for the project itself. At 12 nights, I came across the fact that geolocation in the background does not work well in ReactNative, if you do not write native code, it was a little frustrated. Then it was released when I realized that I was reading the documentation not of the expo.io framework, but of ReactNative. As a result, over the evening it was already clear to me how to get the current position in expo.io and draw separate screens (for login, order display, etc.).
- The application logs in to the checkout counter by code.
- The application immediately shows the available orders, which you need to take orders.
- The courier notes the order and takes the trip.
- He is shown the estimated time and he has time or not.
- The client shows that the courier has left.
- The client begins to show the courier point on the map and the estimated time.
- The courier can write to the client in a chat from the application.
- The client can write a courier to chat from the application.
- Five minutes before arrival, the client receives a message that the courier is close, get ready.
- The courier notes in the app that he pulled up and was waiting.
- The courier calls from the application with one click and reports that (he rises, walks up, etc.)
- The client accepts the order and enters a PIN code from the application or SMS to confirm delivery. (As a signature) So that the courier can not complete the delivery in advance if he is late.
- The order is marked as delivered in the system.
Plus a couple of alternative scenarios:
- The courier can mark the order undelivered and choose a reason.
- Courier, if you are late, you can issue one-button electronic certificate via SMS. Or the certificate comes automatically if the delivery time is not respected.
The sense of promise and need for this project certainly charged.
The next day, we went with the team for lunch and discussed what the minimal functionality of the application would look like.
As a result, the following list of what had to be done on the hackathon was formed:
- Login to the cash desk of delivery.
- Display current position.
- Send data to an external api (coordinates, took the order, delivered the order).
- Get data from external api (current courier orders).
- Send an event that I took a delivery order / delivered.
- Display the current position of the courier on a map in the site.
The main work, as I saw it, was to create the backend, the application itself (after discussions, we chose ReactNative for developing the application, or rather, tying it over - expo.io , which allows you to not write native code at all). In terms of the backend, there was initially hope for Vanya Zverev, as an experienced in working with our service template and k8s (what kind of work he took on himself). ReactNative took me and Andrei Sarafanov.
I decided to try to immediately create a working repository for the project itself. At 12 nights, I came across the fact that geolocation in the background does not work well in ReactNative, if you do not write native code, it was a little frustrated. Then it was released when I realized that I was reading the documentation not of the expo.io framework, but of ReactNative. As a result, over the evening it was already clear to me how to get the current position in expo.io and draw separate screens (for login, order display, etc.).

In the morning at the hackathon, Gleb was drawn into his super-promising project. They quickly laid out a plan of what needs to be done.

They made a mistake when, in accordance with the project template, they tried to make communication not through HTTP, but through GRPC, since no one knew how to build a GRPC client for JavaScript. As a result, having spent about an hour and a half on this, they abandoned this idea. Because of this, the guys and on the back began to redo the finished server from GRPC to WebApi. After half an hour, finally, we were able to configure the application’s communication with the backend, lo and behold. But at the same time, Gleb almost finished off the deployment in k8s and plus auto-deed by committing to the master. :)
As the repository, we chose MySQL so as not to risk even the base (there were thoughts about CosmosDb).

Eventually:
- Implemented saving the current courier coordinates from the application to the database.
- They screwed RabbitMQ and subscribed to messages about the courier taking the order in order to immediately display the order from the courier in the application.
- We began to save time for delivery of the order to our database, after the courier clicked a button in the application. We did not have time to add sending the event back to the rebbit indicating that the order was delivered.
- I did a map display on the currentorder page on the site with the current courier position. But this functionality remained a little unfinished, as the environment could not configure CORS to get the coordinates from our new service.
M87
Roma Bukin, Gosha Polevoy ( georgepolevoy ), Artyom Trofimushkin
We wanted to implement the OpenID Connect provider, as we currently use our own authentication protocol, and this creates a number of difficulties: custom client libraries, inconvenient work from external partners, and possibly problems with security (after all, OAuth2.0 and OpenID Connect in the reference implementation can be considered safe, but as for our solution, I'm not sure).

We made a separate service emulating a personal data storage service in order to create a small model of the Country-Agnostic authentication provider, which would go to a separate service for personal data (this would make it possible in the future to have one service with which you could log in with your account record in any country, and at the same time comply with GDPR and other Federal Laws). We did this part, like the provider, and successfully linked them to each other. Next, it was necessary to make an API that would be protected by tokens issued by the provider, support their introspection through the provider, and send protected data if the request satisfies authorization policies (we verify that the user is authenticated using the Bearer scheme, its token contains a certain scope + the user himself has permissions, allowing the call to be made). This part has also been completed. The last component was a JavaScript client that would be issued a token, with which it would call a secure API. We did not manage to make this part. That is, the entire functional part was ready, but the front-end part was not ready to demonstrate the operability of the entire system.
Uh (igruha)
Dima Afonchenko, Sasha Konovalov
We made a mini-toy on a little one where frisky hands put sausage on pizza. If you incorrectly threw a sausage, the sad message “Rejected” appears on the screen, and if the whole sausage is thrown correctly, a random fact about pizza appears.

They wanted to make the second level with a spread of tomatoes, but did not have time.

Short continuation: who won?
Before the hackathon, we talked with the guys and I asked what prize they would like to receive if they win. It turned out that the road to food would be the most valuable prize.

Therefore, soon expect from us the announcement of the game with handles topping pepperoni on pizza.
As an attentive reader could notice, the team “E-E-E (igruha)” won. Congratulations guys!
Only registered users can participate in the survey. Please come in.
Which project did you like more?
- 9.3% Oleg Lörning (lörning machines) 8
- 58.1% GUI for NOOBS 50
- 10.4% CourierGo 9
- 3.4% M87 3
- 18.6% E-E-E 16