Party hard as a programmer, or as we wrote ClojureCup 2014
Last weekend, the Clojure community was experiencing ... Oh, that was how last year's post began with a report on the past ClojureCup 2013.
ClojureCup is a 48-hour online hackathon, a prerequisite for which is writing applications in Clojure / ClojureScript. This year, about 50 teams participated in the hackathon (each with 1-4 people), who made many cool applications .
Applications are judged by the jury (people known in the Clojure community) and ordinary users: log in using twitter and vote for the applications you like on the application page.
And you can try what we got here .
Caution: under the cut a lot of pictures.
The idea to participate in ClojureCup came up with me a long time ago, but laziness did the trick, and I realized that the team was assembled only three days before the hackathon began (as it turned out, two days before the hackathon it was necessary to form teams). However, this world was not without programmers who wanted to lose their days off in order to write something in a strange language with brackets. Here it is necessary to mention in addition that none of us seriously wrote on Сlojure for some time, and two of them did not write at all. And yes, all four were programmers.
Initially, as a project, there was a desire to do a strange-thing-for-static-sites (one of the teams did something a bit similar in the end), but there were big questions about the need for the result.
As a result, we formed the criteria for choosing an idea: something understandable immediately and for a simple user.
From such criteria, we quickly came to the idea of making some kind of toy. And then I remembered the beautiful Puzzle Bobble :
This is a puzzle with a very mischievous P2P mode: the larger a piece of balls you make as a group, the more of these same balls will come to the enemy. So we focused on finding a game to which we could fasten the mechanics to “make the enemy unpleasant.”
We thought about Tetris, and about 2048, but then they remembered Rocket Mania!
So, at night, two days before the start, the idea of the application was born: two players will play a simplified version of Rocket Mania !, but the number of missiles will be limited and they will fly away to the enemy, and so that the game will ever end, they will have fuel , which decreases with each flight, and at the end the rocket will fly into space forever.
At that time, the game was supposed to be with cool graphics and the ability to play on the network, but when we started working on the idea on Friday night, two changes were made: we decided to throw the game on the network and only support hotseat mode (remember, it was like that in heroes when two player at one computer), and also use flat design, because it’s easier, but among us there are only programmers =)
These were very correct decisions: you need to choose the goals that really can be achieved. Simplify-simplify-simplify.
Like experience in Clojure, we had no experience in the functional style of programming. But here we decided to take the functional paradigm to the fullest: each observation of the world is unchanged , the functions are clean, etc. etc. As a result, in our architecture there was one “atom of the world”, the state of which uniquely determined what was on the screen, and by which the world changed. We also decided to use react.js (it was a very correct solution) and a wrapper over it quiescent (which is incorrect but tolerable). Now it seems to me that it was necessary to look at the phaser , but then such a thought did not arise. By the way, on phaser, another team dida fun game with cats !
In the meantime, the time came to 4 in the morning, ClojureCup began, and we went to sleep. One of the team members (living in a different time zone) at this time raised the server and launched a stub with an Elon Mask rocket there:
The application was very well divided into parts: someone sawed purely game logic, someone displayed the playing field, someone was involved in processing the keyboard. For some reason, we did not happen to actively use the terminal REPL, but figwheel - a solution for automatically recompiling ClojureScript code with hot reload code in the browser - was very helpful and made our life very, very easy. Here one more interesting point should be noted: the state of the world was stored in a non-reloadable atom, so even after recompilation the application remained in the same state as it was before. Of the minuses, we can note that from time to time incremental compilation has flown, we had to do a complete rebuild.
At first, we stored the generated code in the repository, so we gotmagic numbers of tens of thousands of modified lines of code , with a total size of the order of 1K lines of code.
Of the unpleasant fumes, two happened to us:
During the implementation of game logic, we faced the task of large-scale deep changes in the immutable state of the world. As a result, a solution was invented, as it turned out, up to a signature that matches the solution from the standard library =) Moral : study at least a little of the tools that you will use. And before you do something of your own, look: did someone else do it?
And we did not know how to make a mutable state in Clojure (functionaries involuntarily), this gave rise to such a monologue:
As a result, we did not learn how to use a mutable state, but we used a loop.
At the end of the first day, we already had something showing the version of the application, and 3 hours before the end of the hackathon - a more or less full-fledged working version of the game. In the last 3 hours, we added sounds to the game (here we had to abandon the functional paradigm and methods of the form play appeared!) And polished the UI very much.
About 2 hours before the end, our server crashed, and it turned out that the game was distributed by the built-in python server out of the box. Quickly raised nginx and were glad.
Half an hour before the end, I opened the application in Safari, and it turned out that it was generally inactive there (the rotation of the blocks did not work).
15 minutes before the end, we didn’t want sound to work for victory (apparently, there was again a problem with the ClojureScript compiler), all of this markedly added adrenaline.
So even having a more or less working version in 3 hours, we spent the last minutes in a breeze.
And here is this very moment when we started the release version and got three green checkmarks, meaning that we did everything necessary =)
We did, I would like to believe, a fun game for two . And even if it didn’t work out, we got a huge amount of fun and no less experience. Here then you can watch the source code of the project, and then vote, if desired.
A list of projects sorted by current position in a public vote can be viewed here and here . I advise you to look at these lists: among the projects there are very, very decent, funny and useful.
For this year you can already read the reports of Alexander Solovyov (you can know him from this wonderful presentation about FRP and Clojure), Funstructor project teamas well as the Milestones .
Separately want to say thank you to Alexander Solovyov ingspree and Nikita Prokopov tonsky for maintaining interest in Clojure at a high level, as well as Dmitry Grosheva si14 , Nicholas Ryzhikov and Mikhail Lapshin of the workshop held on clojure company JetBrains .
Also many thanks to Julia Belyaeva juliette , Seryozha Serebryakov megaserg and Andrei Siunov fandes for great company at this hackathon. Hackathoning in great company - great!
ClojureCup is a 48-hour online hackathon, a prerequisite for which is writing applications in Clojure / ClojureScript. This year, about 50 teams participated in the hackathon (each with 1-4 people), who made many cool applications .
Applications are judged by the jury (people known in the Clojure community) and ordinary users: log in using twitter and vote for the applications you like on the application page.
And you can try what we got here .
Caution: under the cut a lot of pictures.
Idea
The idea to participate in ClojureCup came up with me a long time ago, but laziness did the trick, and I realized that the team was assembled only three days before the hackathon began (as it turned out, two days before the hackathon it was necessary to form teams). However, this world was not without programmers who wanted to lose their days off in order to write something in a strange language with brackets. Here it is necessary to mention in addition that none of us seriously wrote on Сlojure for some time, and two of them did not write at all. And yes, all four were programmers.
Initially, as a project, there was a desire to do a strange-thing-for-static-sites (one of the teams did something a bit similar in the end), but there were big questions about the need for the result.
As a result, we formed the criteria for choosing an idea: something understandable immediately and for a simple user.
From such criteria, we quickly came to the idea of making some kind of toy. And then I remembered the beautiful Puzzle Bobble :
This is a puzzle with a very mischievous P2P mode: the larger a piece of balls you make as a group, the more of these same balls will come to the enemy. So we focused on finding a game to which we could fasten the mechanics to “make the enemy unpleasant.”
We thought about Tetris, and about 2048, but then they remembered Rocket Mania!
So, at night, two days before the start, the idea of the application was born: two players will play a simplified version of Rocket Mania !, but the number of missiles will be limited and they will fly away to the enemy, and so that the game will ever end, they will have fuel , which decreases with each flight, and at the end the rocket will fly into space forever.
At that time, the game was supposed to be with cool graphics and the ability to play on the network, but when we started working on the idea on Friday night, two changes were made: we decided to throw the game on the network and only support hotseat mode (remember, it was like that in heroes when two player at one computer), and also use flat design, because it’s easier, but among us there are only programmers =)
These were very correct decisions: you need to choose the goals that really can be achieved. Simplify-simplify-simplify.
Like experience in Clojure, we had no experience in the functional style of programming. But here we decided to take the functional paradigm to the fullest: each observation of the world is unchanged , the functions are clean, etc. etc. As a result, in our architecture there was one “atom of the world”, the state of which uniquely determined what was on the screen, and by which the world changed. We also decided to use react.js (it was a very correct solution) and a wrapper over it quiescent (which is incorrect but tolerable). Now it seems to me that it was necessary to look at the phaser , but then such a thought did not arise. By the way, on phaser, another team dida fun game with cats !
In the meantime, the time came to 4 in the morning, ClojureCup began, and we went to sleep. One of the team members (living in a different time zone) at this time raised the server and launched a stub with an Elon Mask rocket there:
Implementation
The application was very well divided into parts: someone sawed purely game logic, someone displayed the playing field, someone was involved in processing the keyboard. For some reason, we did not happen to actively use the terminal REPL, but figwheel - a solution for automatically recompiling ClojureScript code with hot reload code in the browser - was very helpful and made our life very, very easy. Here one more interesting point should be noted: the state of the world was stored in a non-reloadable atom, so even after recompilation the application remained in the same state as it was before. Of the minuses, we can note that from time to time incremental compilation has flown, we had to do a complete rebuild.
At first, we stored the generated code in the repository, so we gotmagic numbers of tens of thousands of modified lines of code , with a total size of the order of 1K lines of code.
Of the unpleasant fumes, two happened to us:
- the first was due to the fact that quiescent was very strange in deciding which parts of the page needed to be updated and which not; at that moment I learned how to embed debug output in the generated JS code and even understand what was generated there,
- the second was apparently a bug of the ClojureScript compiler: the correct code compiled, but then did not work.
During the implementation of game logic, we faced the task of large-scale deep changes in the immutable state of the world. As a result, a solution was invented, as it turned out, up to a signature that matches the solution from the standard library =) Moral : study at least a little of the tools that you will use. And before you do something of your own, look: did someone else do it?
And we did not know how to make a mutable state in Clojure (functionaries involuntarily), this gave rise to such a monologue:
terribly enrages me with a treasure, so that I once again coded on it; why is this language needed, if it is impossible to read, and in order to write something normal, you still need to get out of the concept of the language.
As a result, we did not learn how to use a mutable state, but we used a loop.
At the end of the first day, we already had something showing the version of the application, and 3 hours before the end of the hackathon - a more or less full-fledged working version of the game. In the last 3 hours, we added sounds to the game (here we had to abandon the functional paradigm and methods of the form play appeared!) And polished the UI very much.
About 2 hours before the end, our server crashed, and it turned out that the game was distributed by the built-in python server out of the box. Quickly raised nginx and were glad.
Half an hour before the end, I opened the application in Safari, and it turned out that it was generally inactive there (the rotation of the blocks did not work).
15 minutes before the end, we didn’t want sound to work for victory (apparently, there was again a problem with the ClojureScript compiler), all of this markedly added adrenaline.
So even having a more or less working version in 3 hours, we spent the last minutes in a breeze.
And here is this very moment when we started the release version and got three green checkmarks, meaning that we did everything necessary =)
Instead of a conclusion
We did, I would like to believe, a fun game for two . And even if it didn’t work out, we got a huge amount of fun and no less experience. Here then you can watch the source code of the project, and then vote, if desired.
A list of projects sorted by current position in a public vote can be viewed here and here . I advise you to look at these lists: among the projects there are very, very decent, funny and useful.
For this year you can already read the reports of Alexander Solovyov (you can know him from this wonderful presentation about FRP and Clojure), Funstructor project teamas well as the Milestones .
Separately want to say thank you to Alexander Solovyov ingspree and Nikita Prokopov tonsky for maintaining interest in Clojure at a high level, as well as Dmitry Grosheva si14 , Nicholas Ryzhikov and Mikhail Lapshin of the workshop held on clojure company JetBrains .
Also many thanks to Julia Belyaeva juliette , Seryozha Serebryakov megaserg and Andrei Siunov fandes for great company at this hackathon. Hackathoning in great company - great!