Hack. Sleep. Repeat
Hi all, My name is Dima, and I’m a backend developer at Avito.ru. I participated in a whole bunch of hackathons: small and large, Russian and international, in-house and external, remote, distributed, and classical. I want to tell you how they helped to get acquainted with an old man in Omsk, get infected with cryptobacteria, launch a virtual spacecraft into the Erlang universe, and save humanity from extinction.
I started to attend hackathons as a PHP backend developer with some experience in frontend development. It is quite obvious that at hackathons I wrote in anything but PHP: Python, Rust, Go, Erlang, and other javascripts with react natives. I was very lucky with the team — the guys were strong professionals and really wanted to do something unconventional. Since the first hackathon, we have developed the main criterion for evaluating the idea. It is no more cool than it is crazy. Feasibility, applicability in real life, the possibility of monetization — that’s not really important for us.
A project can be made more crazy, for example, by using rare or non-standard tools. Or using standard tools in an unexpected way. While discussing the project, we tried to bring the degree of craziness to 100%. Evaluation was made by the team members based on the insanity level of the proposed components and solutions.
Years have passed, I have a new job, moved to a different city, and changed the hackathon community. But the focus in the choice of ideas is still on craziness. Here I’ll tell you about some projects that I have worked on at external hackathons.
Projects
ndrctl
It is pronounced “indirectly”. A multiplayer two-dimensional game in the open universe. Spacecraft fly, attack each other and space objects. In the plans — trade and other nice things. But this is not enough. And what if we make the starship controls indirect (hence the name of the project)? Suppose that you can not simply send the ship to the left. But we can put two engines on the left and right and allow the player to control their thrust. You want to fly to the left? Turn the ship in the right direction by controlling the thrust of both engines, then give full throttle. +10 craziness points. How to make it even more fun? Flying the ship using code. Some trivial PHP or Python code. Another +10. This was how the craziness scale worked. As you can see, in its existing form, the idea was not yet worthy of implementation.
At that time, we were creating development environments at work. Those were wild days, Docker was in its infancy, guys at Google had not yet thought of Kubernetes, no ready-made solutions existed. We had some pressing problems with virtualization and containerization, isolation, rapid deployment of snapshots. Obviously, all this infrastructure was used to create a game.
Each spacecraft was an lxc-container, protected by a set of apparmor-rules. Engines, radars, and other components were mounted as block devices. The code loaded by the player into the ship could interact with the devices, and this was the only way to interact with the universe. You want to know where you are — read the sensor data. You want to send the ship to a certain point — you control the engine thrust. Since the ships were containers, the player could write code in any language.
And the universe was in Erlang. It generated tics, determined the physics, calculated the position of the ships based on the engine thrust, distributed the sensor readings. It was Erlang because the leader of our team was interested in functional programming languages at that moment.
We visualized in html5, svg. At the demonstration, they tried to download the snippet code, which forced the ship to fly in circles. But it would stubbornly rotate and fly spiraling into the open space. This is how we wrote the first game in our life, in which we lost.
cryptobact
The user’s device (laptop, phone, tablet) is colonized by bacteria. They eat, regenerate, attack enemies. A multiplayer game in an almost real world.
When the game starts, a unique fingerprint is collected from the device. On its basis, DNA is formed. During reproduction, an evolutionary algorithm with random mutations is activated. New generations of bacteria can be faster or slower, lustful or chaste, gluttonous or abstemious, resistant to environmental impacts or have reduced immunity.
Users on the same Wi-Fi network can exchange strains of their bacteria with a certain probability. At the same time, a colony of bacteria that has settled on someone else’s device can start attacking enemy bacteria. Or assimilating with them. Or can be killed by them.
At that time, the bitcoin was conquering the planet, everyone was interested in the blockchain. We decided to use a similar algorithm to sign the evolutionary steps. This made impossible fast-forwarding the evolution on a single device to develop bacterial super-strains.
We used OpenGL for visualization. And it is based on triangle meshes. Halfway through the night I had to convert bacteria images into triangle meshes to get their vertex coordinates. And still missed one of the vertices — one of the bacteria had a corner sticking out. We made an Android app, installed it on the devices of all interested hackathon participants, and infected them with cryptobacteria.
go-android-rpc
At one of the distributed international hackathons, it was decided to build the world’s first Android app written completely in Go. At that time, it was already possible to build OpenGL apps in Go. But it’s all triangle meshes. And we wanted to use an SDK with buttons and text boxes to avoid having to draw everything ourselves. SDK is in Java. We write in Go. No problems were expected.
We set up an RPC server on Java, and Go acted as a client sending commands that were translated into Java commands. We parsed the SDK documentation and generated mirrored calls for Go. The Go command was sent to Java, the output was sent back. We were able to create buttons by calling the appropriate SDK methods.
The trouble is that SDK methods often take objects. We could not find a way to connect the Go structures with Java objects. So, we had to content ourselves with those methods that accepted scalars. Those methods were enough to create a text spaceship disaster quest in the spirit of the 80s.
apisal
We participated in a thematic hackathon devoted to services for the city. We built a service that takes a GPS track as an input to find points of interest along the route and shows them as an HTML page. A kind of report generator for lazy bloggers.
Inside it, we decided to implement an a la unix pipe. One part parses wikimapia, the other parses gpx tracks, the third smooths the angles in the route, the fourth generates the report. Parts are substituted and combined. Can be written in any language, as long as the given interface is implemented.
moov
We continued to develop the idea about routes and points of interest. The goal was to get real-time information about what can be seen in the area. And to try the react native. We built an app with a map of points of interest located nearby. It was an extensive plan — making it possible to add a route planner, attach social elements (who of your friends has recently traveled and what they have seen), generate a report using apisal from the recorded track. But we were interested in the react native.
resurrect-the-evolution
We decided to conduct a mental experiment. The Earth perished, but the mankind managed to build a starship for colonists and genetic material and send it to a liveable planet in a distant galaxy. Technically, everything went well. They landed, unpacked the suitcases, unfroze the genetic material and the new generations were born. But there was no cultural diversity, since the humans had spent hundreds of years on the spaceship. They were all very similar — same language, same cultural background. And they brought up the new generations in the same way, were being unable to teach them sufficient breadth of thinking to solve the piling up problems of the new world.
The colonists found a solution — settle the new planet in independent groups, almost completely prevent communication between groups for several centuries, create new customs and traditions, create a new language for each of the groups. Later, the borders will open and everybody will enjoy the brave diverse world.
We concentrated on one of the tasks — creating a language for each of the groups. We wrote a human language generator that takes the name of the language as the input, and generates a ready for use language as its output. You can load a small text in English and get an approximate translation into the generated language. There were plans to create materials for learning the languages — spelling, grammar, dictionaries, textbooks.
Fun facts
All kinds of things happen at hackathons. For example, you may find yourself deep in snow in slippers in the winter. Or in an ice-hole with the Finns. Or — god forbid — in Omsk. But first things first.
One day, there was a hackathon in Omsk, and we were not allowed to sleep at the venue. We had to find a hostel and check in to be able to code. We found a house, dialed the apartment number on the intercom, and some old man answered. It was a very polite old man, by Omsk standards:
— Who’s there?
— We are staying at the hostel.
— What hostel? I don’t know you, I won’t let you in.
— Oh, sorry, I think it was wrong building.
— Really? Get out with you!
Novosibirsk Science Campus has a remarkable technopark building. Hackathons are often arranged there. My first hackathon was held there, arranged by a modest American search engine, who had a conference in the next room with some very tasty kebabs. Don’t even ask how I know.
As it turned out at a different hackathon, the WCs in the technopark building get sometimes clogged. And the gallery to another part of the building is closed at night. It’s cold in Novosibirsk. And snows. A security guard in the adjacent part of the building was very surprised when, in the middle of the night, a flock of sleepy IT people rushed in slippers through the snow to the restroom.
To one of the hackathons, I had to travel 20 kilometers by bike. After two almost sleepless days, I had to ride back late at night. A short stretch of the road had no streetlights at all, and I had no headlight on the bike. Fortunately, there are few cars there at night. During the ride I tried closing my eyes. It turned out that there was no difference — you can not see anything anyway, and you still immediately feel that you are riding on the road shoulder.
The hardy Finns are not afraid of cold and snow. At a hackathon in Helsinki, we went for a walk in the downtown. Nearby there was a pier with an improvised ice-hole with some bathing Finns. It was winter and cold. We could hardly refrain from joining them.
At another hackathon, one jury member enjoyed our project, and recommended a friend who paid for our flight to a hackathon in Moscow.
At one hackathon, we experienced the overpopulation problem. When we were looking for a place where we could work in peace and quiet, it turned out that everything was occupied, and we could only get half of a table for three of us. Then we asked if they had a room. The reply was a confident no. We did not get lost and asked if they had a floor. And they had it! We spent two days on an almost empty floor at the beautiful Moscow business centre “Arma”, running after the sun, watching sunrises and sunsets.
Tactics
At hackathons I love doing something strange, unnecessary, but inherently interesting. Trying to combine the incompatible, use tools in a strange way. Quite an option. But there may be others. You can concentrate on solving a problem that haunts your mind: write a plugin for your favorite editor to get rid of annoying operations, automate a routine process at work, organize photos or documents.
A promising direction is the search for new approaches to familiar things. A good example is Tinder. Dating services have been around for years, and these guys managed to find a new mechanic that lots of people liked.
You can make self-development the main value and set goals at a hackathon based on the tools that you want to learn. If you have always dreamed of learning Rust — it’s time to do it. My colleagues have positive experience with this.
Many hackathons offer mentoring. They invite experts who assess the potential of the idea in terms of monetization and scalability. For those wishing to try their hand at a startup or accelerator, the hackathon can be a good format for building a prototype and trying to “sell” it to sponsors.
Benefit
Each programmer has a set of cold and hot skills. Hot skills are the technologies and tools that are used in daily work. Cold skills are those that the programmer has some idea about, but needs time to start using — to read the documentation, to experiment with the prototype. Hackathons allow us to quickly transform some of the skills from cold to hot.
Solution tested at hackathons often come useful at work. There are examples of implementation of tools developed at a hackathon.
The hackathon format is very convenient for testing the hypothesis of a working product. In existing large systems, there is the burden of preexisting code, business processes that need to be considered if you want to make serious changes. Hackathon allows to implement some part of the project in a completely different way, without looking back on this legacy.
An excellent bonus is the opportunity to spend a few sleepless nights in the offices of different IT companies — many of them host hackathons, which is a chance to have a look from the inside. You can travel to different cities and even countries — some hackathons are held in several stages, and the winners of the stages are invited to take part in the finals in capitals or abroad.
Preparation
The main thing at any hackathon is slippers. Two days of hard work require concentration. Nothing should distract you. Create the most comfortable conditions for work.
Think in advance how you will sleep. The hardcore alternative is not to sleep at all. I have tried this, it works. But with age, it becomes more difficult. If you decide to sleep, make sure that other participants can continue working without you, and you easily return to work when you wake up. The solution is parallelizing tasks and freezing the interfaces at key points.
Soda is the best time of sleep controller. After drinking enough of it, no one can sleep longer than one hour. Alcohol is not a solution — it makes you sleepy and it’s much harder to think. At a distributed hackathon, we tried worked at a friend’s place. There we tried making some really strong coffee. Extremely effective whenever you need to stay awake. And sort out what you are going to eat. Finding food can take lots of time. If necessary, bring soda and meals.
Think about the idea in advance. This is the most time consuming process. After choosing an idea, decide on the technologies you want to use, search the GitHub and the web for suitable tools. Read the documentation, find posts, examples.
Prepare a plan of producing prototypes ready for demonstration. The first prototype should be ready in a few minutes. It can be real hardcode inside, but you should be able to show what you’re trying to do. The second and subsequent prototypes should be ready in a short time (a couple of hours) and be a system ready for demonstration, where there is less and less hardcode and more and more real working code.
Afterword
Hackathons are a good experience. This conclusion is follows directly from the fact that they have multiple pros and not a single con. Hackathon is worth postponing your other plans and spend several dozens of hours with your colleagues and some code.
It makes sense to arrange such events inside mid-sized businesses and large corporations. In a small business context, you can join like-minded people and attend an external hackathon as one or more teams. And since hackathons are so useful and Avito is a large corporation, we have decided to hold internal hackathons. In fact, we have held our eighth hackathon recently.
In the next post, I’ll tell you about Avito’s in-house hackathons. A little about the organization, Technical and Big Pack, where the Centi-Code is heading, and a lot about the projects that we developed — usefulness for the inner workings and the open source community.
