Hey 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.
The boring part for those interested in marketing
I'll start with a little story.
Beginning of April. Our office hosts the first MskDotNet Community hackathon. The battle for Tatooine is in full swing, in our galaxy this time. Saturday. 20 teams. Pizza. It's all very soulful). An inflatable R2-D2 looms around the room. Teams write the most correct algorithms to pass the most dangerous race on the map. We are moving the launch of the first races. Cookies and coffee save. The organizers and I expected that many people would leave after lunch on Saturday. 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 on Slack and the idea comes to my mind: “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 approaching from behind. "Lisa, this is great! April 21 is an important date for us. Let's do it! WTF!? So fast? A? What? I need to fly to Syktyvkar for an internship in mid-April. Yes, to hell with him! Let's.
There are 2 weeks left. I have never been the sole organizer of a hackathon. Let and internal. I read articles on this topic. Tin. It takes several months. Several people are needed. You need to think over the merch, prizes, conditions, schedule, get interested, understand the goal, budgets. And maybe even understand the meaning of life. I definitely won't make it. And while you were reading and preparing, a week had already passed. It's time to score on the articles and start doing something.
Check out our 1 week internal hackathon checklist
- Plan: calmly sit down and write a list of what needs to be done for the hackathon. 30 minutes.
- Task: Participants themselves propose and select projects they want to create in Google Sheets. Background task, 2 hours.
- Schedule: on your knee you write a short breakdown of time, taking into account 3 breaks and the final. 20 minutes.
- commands: publish a message about a hackathon with a 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 the undecided do it in the first 5 minutes of the hackathon. Background task, 2 hours.
- Buns: you come up with merch with two developers, give it to the designer for rendering, and you get it ready. Background task, 3 days.
- Hackathon: you come to the office, coordinate everyone at the beginning, go about your business, read Reddit, importantly report every break about fresh pizza, photograph the sunset, announce the final, vote together and choose the winner. 1 day.
- Under the asterisk: Of course, you constantly think about everything going well. Of course, not everyone will see your message and it is better to talk to some in person. Of course, if someone helps you, everything will become 2 times easier (the wonderful Alena helped me).
The less boring part about the hackathon date
Why April 21st? This day is significant for us. Exactly one 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 am. Then we created the sundayhackathon board in Trello and started a week of shift work of 12 hours a day. The situation was so critical that we didn’t even have time to eat and we were fed by guys from other teams.
You can read a more detailed story at (our CEO). Since then, we have changed a lot, but now we will definitely not forget the date.
This year, we decided that this event should be immortalized in the memory of posterity and, in the best traditions, arranged 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 Lerning (machine learning)
Dima Kochnev, Sasha Andronov (@alexandronov)
We 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, roughly figured out how everything works, as far as possible in a day (~ 10 hours).
In particular, we realized that the industry has reached a level where an ordinary developer can take ready-made libraries, read the documentation and train their own neural network without deep knowledge of the subject. And it will work well enough to solve real problems.
Tools used:
- is a convenient and simple library for working with machine learning and computer vision.
- Models tried two - ResNet50, Yolo.
- The code was written, of course, in python.
We had 11000 photos, but among them, almost 3/4 turned out to be garbage, and in the rest - different, inappropriate angles. As a result, we took a ready-made model (which just knows how to find pizza) and with its help we separated the trash itself. Further, the name of the photo was the name of the pizza - so we sorted it into folders, but it turned out that the names did not match reality and here 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 turned out to be enough to separate 10 pizzas from one another.
To train the grid, we took the cheapest virtual machine in Azure on NVIDIA Tesla K80. It was trained in 100 epochs, but it was clear that the network was oversaturated after 50 epochs, due to the fact that there was a small dataset.
Actually - the whole problem is the lack of good data.
We may have got a little confused in terms, but we must bear in mind that we generally have no experience in working with all these cases.
GUI for NOOBS (pizza ordering console)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
We have put together a prototype console application for geeks, thanks to which you can order pizza through the terminal or command line, or even embed it in the deploy pipeline and, upon successful release, deliver pizza to the office.
The work was divided into several parts: we figured out how our API for mobile applications works, we built our own CLI using and set up the publication of the package we assembled. The last task had several unpleasant minutes towards the end of the hackathon. Everything worked locally for us and even the old published versions of the package worked, but the new ones (which added more cool features and emoticons) refused to work. We spent about 40 minutes to figure out what went wrong, but in the end everything magically worked by itself).
Our program for the maximum hackathon was a real pizza order to the office through our CLI. We ran everything on the test bench a dozen times, but my hands were still shaking when I scored commands on the prod.
As a result - we still did it!
CourierGo
Anton Bruzhmelev (author), Vanya Zverev, Gleb Lesnikov (), Andrey Sarafanov
They took the idea of "Application for a courier".
Background on preparation.Initially, I figured out what features can be in the application? A list of features came up like this:
- The application logs in to the delivery checkout using the code.
- The application immediately shows available orders, orders that need to be taken.
- The courier notes the order and takes it on a trip.
- He is shown the estimated time and whether he has time or not.
- The client shows that the courier has left.
- The client starts showing 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 to the courier in a chat from the application.
- Five minutes before arrival, the client receives a message that the courier is close, be prepared.
- The courier notes in the application that he has arrived and is waiting.
- The courier calls from the application with one click and reports that (rising, approaching, etc.)
- The client accepts the order and enters the pin code from the application or SMS to confirm the delivery. (as a signature) So that the courier could 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 as undelivered and select a reason.
- The courier, if late, can issue an electronic certificate via SMS with one button. Or the certificate comes automatically if the delivery time is not met.
The feeling of the prospects and necessity of this project, of course, was energizing.
The next day, I went to lunch with the team and discussed what the minimum functionality of the application would look like.
As a result, the following list of what had to be done at the hackathon was formed:
- Login to the delivery checkout.
- Display current position.
- Send data to external api (coordinates, took the order, delivered the order).
- Get data from external api (current courier orders).
- Send an event about the fact that he took the order for delivery / delivered.
- Display the current position of the courier on the map in the site.
The main work, as it seemed, was to create the backend, the application itself (after discussions, we chose ReactNative to develop the application, or rather, the binding above it - , allowing you not to write native code at all). In terms of the backend, initially there was hope for Vanya Zverev, as he was experienced in working with our service template and k8s (which job he took on). ReactNative was touched by me and Andrey Sarafanov.
I decided to try to immediately create a working repository for the project itself. At 12 at night, I came across the fact that geolocation in the background does not work well in ReactNative, if you do not write native code, I was a little frustrated. Then I let go when I realized that I was reading the documentation not of the expo.io framework, but of ReactNative. As a result, in 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, they lured Gleb into their super-promising project. They quickly came up with a plan of what to do.
They made a mistake when, in accordance with the project template, they tried to make communication not via HTTP, but via GRPC, since no one knew how to build a GRPC client for JavaScript. As a result, after spending about an hour and a half on this, they abandoned this idea. Because of this, the guys on the back began to remake the finished server from GRPC to WebApi. After half an hour, finally, we were able to set up communication between the application and the backend, lo and behold. But at the same time, Gleb almost finished deploying to k8s and plus auto-deploying by commit to the master. 🙂
As a storage, we chose MySQL so as not to risk at least with the database (there were thoughts about CosmosDb).
In summary:
- Implemented saving the current coordinates of the courier from the application to the database.
- We screwed RabbitMQ and subscribed to messages about the order being taken by the courier in order to immediately display the order from the courier in the application.
- We began to save the time of delivery of the order to the database after the courier pressed the button in the application. We didn’t have time to add sending an event back to the rebbit that the order was delivered.
- I made a map display on the currentorder page on the site with the current position of the courier. But this functionality remained a little unfinished, since it was not possible to configure CORS on the environment to receive coordinates from our new service.
M87
Roma Bukin, Gosha Polevoy (), Artyom Trofimushkin
We wanted to implement an OpenID Connect provider, since at the moment we use our own authentication protocol, and this creates a number of difficulties: custom client libraries, inconvenient work from external partners, possibly security problems (after all, OAuth2.0 and OpenID Connect in the reference implementation can be considered safe, but I'm not sure about our solution).
We made a separate service that emulates a personal data storage service in order to create a small model of a Country-Agnostic authentication provider that would go for personal data to a separate service (this would make it possible in the future to have one service with which one could log in with an account recording in any country, and at the same time comply with the GDPR and other federal laws). We did this part, just like the provider, and successfully linked them to each other. Next, it was necessary to make an API that would be protected by the tokens that the provider issues, support their introspection through the provider and return secure data if the request would satisfy the authorization policies (we check that the user is authenticated according to the Bearer scheme, his token contains a certain scope + the user himself has a permission that allows the call to be made). This part has also been completed. The last component was a JavaScript client that would be given a token with which to call a secure API. We didn't get to do this part. That is, the entire functional part was ready, but the front-end part was not ready to demonstrate the performance of the entire system.
E-E-E (toy)
Dima Afonchenko, Sasha Konovalov
We made a mini-toy on a yunk where frisky hands put a sausage on a pizza. In case you put the sausage on incorrectly, the sad inscription “Rejected” appears on the screen, and if the whole sausage is thrown on correctly, then a random fact about pizza appears.
They wanted to make the second level with throwing tomatoes, but did not have time.
Short sequel: 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 most valuable prize will be "the road to the prod."
Therefore, expect us to announce a game with pens that throw pepperoni on pizza soon.
As an attentive reader could notice, the team "E-E-E (toy)" won. Congratulations guys!
Only registered users can participate in the survey. , you are welcome.
Which project did you like best?
-
Oleg Lerning (machine learning)
-
GUI for NOOBS
-
CourierGo
-
M87
-
Uh-uh
5 users voted. 3 users abstained.
Source: habr.com