October 21, 2013 at 17:56A play in two acts about sports and rails
This year we decided to participate in RailsRumble - a competition for Rails developers, where teams must provide a fully working website with a great idea in 48 hours. I'd like to share with the habrasociety the impression of participation in the competition.
Our project is a site for football fans who are interested in the life of their idols on social networks: Sport for Social Fans .
Below is a small play in two acts, with five characters and intermission.
In the first lines of the letter, we began to search for a topic. As a result of the brainstorming, we got almost 20 different ideas. The most promising revolved around sports, travel and development. After discussion, sports came to the top - and we started digging.
Spent three days sluggishly on ongoing discussions and brainstorming sessions.
At this stage, the most difficult was to crystallize the idea of a future service. And to do this not in an airless space, but based on the conditions of the competition - we will have no more than 48 hours and 4 people to develop. And yes, of course, victory is not the main thing, participation is the main thing, but the service should attract users and arrange judges.
It was one of the most difficult stages. We acted on the principle of crossing out, and the logic of the zoom was something like this:
sport -> popular sport -> football -> fans -> follow the club / player.
At the output, we got the idea: to create a website that helps fans to track their social activity teams on social networks (Facebook, Twitter, Instagram).
It took another day.
In this action, the most difficult was not to succumb to the temptation and to answer “no” to at least every second sentence on features. In total, we said “no” about ten times, for example, badges for users, registration and pre-moderation. And so far they have not regretted it.
A dozen “no” provided us with a few fat “yes”: search by team and player, translation of official user accounts and posts by hashtags, a little statistics. We collected static information and started working on the design.
Spent one day.
In this place we take a break - about the design, presumably, not so interesting. We will only say that we focused on attractiveness and usability.
I wanted to attract the user with the design, but to keep the content and convenience. It seems to work out .
The last thing I want to add before the intermission: we (honestly, honestly) did not cheat and did not touch the code before the start of the fight. The design was the last pre-harvest.
The prototype interface and design took two days.
While you are standing in line for a cap of espresso (with cognac, of course) and a sandwich with caviar, we will tell you a little about our disposition before the fight. So, our troupe has one designer, one frontend and two backend developers. And the director, the manager, is behind the scenes.
Geography: Novokuznetsk, Tolyatti, Mariupol, Guadalajara (unexpectedly?). This was our trump card - after the start, we were able to write code continuously for all 48 hours. * the third bell rings *
In terms of technology, we wanted to be on top. Took:
Ruby on Rails 4 ,
nginx + unicorn + capistrano
Postgres + redis
faye
coffeescript , ember.js We
clearly defined the responsibilities of everyone in the team. Tons of work fell on the backend, so the geographic location of the developers helped us a lot.
Difficulties were with a huge amount of data entered into the database.
We track more than 400 hashtags and accounts of players, teams in three social networks: Facebook, Twitter, Instagram. Every second, more than 100 messages are generated, the base is rampant, and we must withstand the load (and the habr effect too). The task is interesting.
To begin with, we decided to store user posts in Postgres. Without redis not done, t. To. messages go in a stream, each time to check whether this or that is in the database, it would be too wasteful.
Redis organized a cache by message id. SortedSet was used: due to the fact that the add and check operation has log (n) complexity, we planned not to lose performance on this. The priority parameter was the time of addition. We did not want to keep all the id records forever and therefore deleted posts with low priority (in our case, this is a measure of time).
The second point of using redis (although it did not reach it): despite the fact that faye uses pub / sub, we were afraid to send all incoming messages. We decided to use a scheme in which, when a user enters the site, the front sends a request to the controller with the id of the entity for which the messages are needed. And so he does every minute while the user views the page.
This lock is written to redis, where it is deleted after about a minute if a second request does not arrive. Meanwhile, when creating messages, the hook that publishes in faye, with each attempt, checks to see if anyone is waiting for this message at all. And, if no one is waiting, skips this action.
The front, as we said, on ember.js. This turned out to be a great choice for a quick one-page application. True, because of the difficulties that arise even with a slight deviation from his ideology of developing web applications, after unsuccessful searches for a solution, I had to redo the interface for it.
It was difficult to adhere to the party line - minimalism. 48 hours is much less than required. And you had to continue to limit yourself in your desires.
We did not have much time - for example, we were more concerned with code than with content for users. We see a problem in that, having visited the site, not everyone will quickly figure out why.
We consider it a big omission that we turned to the judges and turned out to be a bit half-turned towards the user. We do not have descriptions of why our application is needed and how to use it - that is, there is practically no promotional content.
Not everything in the front is perfect. We did not have time to hone the interfaces to the end.
We did not have time to fully test the demons that collect content from social networks. If problems arise, god, of course, restarts everything, but some of them are still not clear.
There was not enough time to add realtime to the project with faye, although everything was ready for this. As planned, the number of posts, subscribers and new posts should be updated automatically, producing a wow-effect and causing a storm of applause.
But overall, we are pleased with the work done. And how much a working and interesting project we have succeeded in is up to you.
I would like to wish good luck to all teams from Russia.
Here is a list of those we found, probably there are many more.
rb.r13.railsrumble.com
octoscrum.r13.railsrumble.com
listio.us
object.r13.railsrumble.com
undev-angels.r13.railsrumble.com
talk-tree.r13.railsrumble.com
www.trackcha.com
railsrumble.com / entries / 54-sevastopol-rb
plugin.r13.railsrumble.com
getbacktoreading.com
tip4commit.com
Our project is a site for football fans who are interested in the life of their idols on social networks: Sport for Social Fans .
Below is a small play in two acts, with five characters and intermission.
Branch One
Preamble
In the first lines of the letter, we began to search for a topic. As a result of the brainstorming, we got almost 20 different ideas. The most promising revolved around sports, travel and development. After discussion, sports came to the top - and we started digging.
Spent three days sluggishly on ongoing discussions and brainstorming sessions.
Outpatient work
At this stage, the most difficult was to crystallize the idea of a future service. And to do this not in an airless space, but based on the conditions of the competition - we will have no more than 48 hours and 4 people to develop. And yes, of course, victory is not the main thing, participation is the main thing, but the service should attract users and arrange judges.
It was one of the most difficult stages. We acted on the principle of crossing out, and the logic of the zoom was something like this:
sport -> popular sport -> football -> fans -> follow the club / player.
At the output, we got the idea: to create a website that helps fans to track their social activity teams on social networks (Facebook, Twitter, Instagram).
It took another day.
Mom, mom, what will I do
In this action, the most difficult was not to succumb to the temptation and to answer “no” to at least every second sentence on features. In total, we said “no” about ten times, for example, badges for users, registration and pre-moderation. And so far they have not regretted it.
A dozen “no” provided us with a few fat “yes”: search by team and player, translation of official user accounts and posts by hashtags, a little statistics. We collected static information and started working on the design.
Spent one day.
Here the fish was wrapped
In this place we take a break - about the design, presumably, not so interesting. We will only say that we focused on attractiveness and usability.
I wanted to attract the user with the design, but to keep the content and convenience. It seems to work out .
The last thing I want to add before the intermission: we (honestly, honestly) did not cheat and did not touch the code before the start of the fight. The design was the last pre-harvest.
The prototype interface and design took two days.
Intermission
While you are standing in line for a cap of espresso (with cognac, of course) and a sandwich with caviar, we will tell you a little about our disposition before the fight. So, our troupe has one designer, one frontend and two backend developers. And the director, the manager, is behind the scenes.
Geography: Novokuznetsk, Tolyatti, Mariupol, Guadalajara (unexpectedly?). This was our trump card - after the start, we were able to write code continuously for all 48 hours. * the third bell rings *
Last branch
Speech Technique
In terms of technology, we wanted to be on top. Took:
Ruby on Rails 4 ,
nginx + unicorn + capistrano
Postgres + redis
faye
coffeescript , ember.js We
clearly defined the responsibilities of everyone in the team. Tons of work fell on the backend, so the geographic location of the developers helped us a lot.
Difficulties were with a huge amount of data entered into the database.
We track more than 400 hashtags and accounts of players, teams in three social networks: Facebook, Twitter, Instagram. Every second, more than 100 messages are generated, the base is rampant, and we must withstand the load (and the habr effect too). The task is interesting.
To begin with, we decided to store user posts in Postgres. Without redis not done, t. To. messages go in a stream, each time to check whether this or that is in the database, it would be too wasteful.
Redis organized a cache by message id. SortedSet was used: due to the fact that the add and check operation has log (n) complexity, we planned not to lose performance on this. The priority parameter was the time of addition. We did not want to keep all the id records forever and therefore deleted posts with low priority (in our case, this is a measure of time).
The second point of using redis (although it did not reach it): despite the fact that faye uses pub / sub, we were afraid to send all incoming messages. We decided to use a scheme in which, when a user enters the site, the front sends a request to the controller with the id of the entity for which the messages are needed. And so he does every minute while the user views the page.
This lock is written to redis, where it is deleted after about a minute if a second request does not arrive. Meanwhile, when creating messages, the hook that publishes in faye, with each attempt, checks to see if anyone is waiting for this message at all. And, if no one is waiting, skips this action.
The front, as we said, on ember.js. This turned out to be a great choice for a quick one-page application. True, because of the difficulties that arise even with a slight deviation from his ideology of developing web applications, after unsuccessful searches for a solution, I had to redo the interface for it.
Marathon
It was difficult to adhere to the party line - minimalism. 48 hours is much less than required. And you had to continue to limit yourself in your desires.
We did not have much time - for example, we were more concerned with code than with content for users. We see a problem in that, having visited the site, not everyone will quickly figure out why.
Curtain
Debriefing
We consider it a big omission that we turned to the judges and turned out to be a bit half-turned towards the user. We do not have descriptions of why our application is needed and how to use it - that is, there is practically no promotional content.
Not everything in the front is perfect. We did not have time to hone the interfaces to the end.
We did not have time to fully test the demons that collect content from social networks. If problems arise, god, of course, restarts everything, but some of them are still not clear.
There was not enough time to add realtime to the project with faye, although everything was ready for this. As planned, the number of posts, subscribers and new posts should be updated automatically, producing a wow-effect and causing a storm of applause.
But overall, we are pleased with the work done. And how much a working and interesting project we have succeeded in is up to you.
Afterword
I would like to wish good luck to all teams from Russia.
Here is a list of those we found, probably there are many more.
rb.r13.railsrumble.com
octoscrum.r13.railsrumble.com
listio.us
object.r13.railsrumble.com
undev-angels.r13.railsrumble.com
talk-tree.r13.railsrumble.com
www.trackcha.com
railsrumble.com / entries / 54-sevastopol-rb
plugin.r13.railsrumble.com
getbacktoreading.com
tip4commit.com