A play in two acts about sports and rails
This year, we decided to participate in RailsRumble , a competition for Rails developers, where teams should provide a fully working website with a great idea in 48 hours. I'd like to share with Habrasoobschestvom impression from 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 piece in two acts, with five characters and an intermission.
')
In the first lines of the letter we started searching for a topic. As a result of brainstorming, we got almost 20 different ideas. The most promising ones revolved around sports, travel and development. After discussing the top sport came out - and we started digging.
We spent three days sluggishly on current discussions and brainstorming.
At this stage, the most difficult thing was to crystallize the idea of ​​the future service. And to do this not in a vacuum, but based on the conditions of the competition - we will have no more than 48 hours and 4 people for the development. And yes, of course, the victory is not the main thing, the main thing is participation, but the service must attract users and locate the judges.
It was one of the most difficult stages. We acted on the principle of deletion, and the logic of the zoom was something like this:
sport -> popular sport -> football -> fans -> club / player following
At the exit, we got the idea: to make a website that will help fans track the social activity of their team in social networks (Facebook, Twitter, Instagram).
It took another day.
In this action, the most difficult was to resist the temptation and at least every second sentence on the features to answer "no." Total, we said “no” about ten times - for example, user badges, registration and pre-moderation. And while this is not regretted.
A dozen "no" provided us with a few fat "yes": search by team and player, broadcast official accounts and posts of users by hashtags, a bit of statistics. We collected static information and went to work on the design.
Spent one day.
In this place we will take a pause - about the design, I suppose, not so interesting. We can only say that we focused on attractiveness and usability.
I wanted to attract the user with the design, and keep the content and convenience. It seems to work out .
The last thing I want to add before the intermission: we (honestly and honestly) did not cheat and did not touch the code before the start of the fight. The design was the last preparatory.
The prototype interface and design took two days.
While you are standing in line for an espresso cap (with cognac, of course) and a caviar sandwich, we'll tell you a bit about our disposition before the fight. So, in our troupe there is one designer, one frontend and two developer backends. And the director manager is backstage.
Geography: Novokuznetsk, Tolyatti, Mariupol, Guadalajara (unexpected?). It was our trump card - after the start we were able to write code continuously for 48 hours. * the third bell rings *
From the point of view of technology, we wanted to be on top. Have taken:
Ruby on Rails 4 ,
nginx + unicorn + capistrano
Postgres + redis
faye
coffeescript , ember.js
Clearly distributed the responsibilities of each in the team. Tons of work went on the backend, so the geographical location of the developers helped us a lot.
Difficulties were with a huge amount of data stored in 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 database is growing impetuously, and we have to withstand the load (and the habr effect too). The task is interesting.
To begin with, we decided to store user posts in Postgres. It’s not without redis, because the messages are streaming, it would be too wasteful to check every time whether this or that is in the database.
Redis organized a cache by id messages. SortedSet was used: due to the fact that the operation of adding and checking has log (n) complexity, we planned not to lose performance on this. Also, the priority parameter was the time to add. We did not want to keep all id records forever and therefore deleted posts with low priority (in our case, this is a measure of time).
The second moment of using redis (although it didn’t get to 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 visits the site, the front sends a request to the controller with the id of the entity that needs messages. And so he does every minute while the user views the page.
This lock is written to redis, where after about a minute it is deleted if a second request is not received. In the meantime, when creating messages, the hook that publishes on the faye checks with each attempt: if anyone is waiting for this message at all. And, if no one waits, skip this action.
Front, as we said, on ember.js. This turned out to be a great choice for a quick one-page application. However, due to the difficulties that arise even with a slight deviation from its ideology of web application development, after unsuccessful search for a solution, the interface had to be redone.
It was difficult to adhere to the line of the party - minimalism. 48 hours is much less than required. And it was necessary to continue to limit themselves in their desires.
We did not have much time - for example, we were more involved in the code than in content for users. The problem we see is that, having entered the site, not everyone will quickly figure out why he is.
We consider as a big omission the fact that we turned to face the judges and turned out to be a little half-turned towards the user. We have no descriptions of why our application is needed and how to use it - that is, there is practically no promotional content.
Not everyone in the front is perfect. We did not have time to hone the interfaces.
We did not have time to fully test the demons involved in collecting content from social networks. If problems arise, god, of course, restarts everything, but part of them is still not clear.
There was not enough time to add a real-time project to the faye, although everything was ready for this. As planned, the number of posts, subscribers and new posts had to be updated automatically, producing a wow-effect and causing a storm of applause.
But in general, we are pleased with the work done. And how workable and interesting the project we have turned out is up to you.
I would like to wish good luck to all the teams from Russia.
Here is a list of those we found, for sure 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 piece in two acts, with five characters and an intermission.
')
Branch first
Preamble
In the first lines of the letter we started searching for a topic. As a result of brainstorming, we got almost 20 different ideas. The most promising ones revolved around sports, travel and development. After discussing the top sport came out - and we started digging.
We spent three days sluggishly on current discussions and brainstorming.
Outpatient work
At this stage, the most difficult thing was to crystallize the idea of ​​the future service. And to do this not in a vacuum, but based on the conditions of the competition - we will have no more than 48 hours and 4 people for the development. And yes, of course, the victory is not the main thing, the main thing is participation, but the service must attract users and locate the judges.
It was one of the most difficult stages. We acted on the principle of deletion, and the logic of the zoom was something like this:
sport -> popular sport -> football -> fans -> club / player following
At the exit, we got the idea: to make a website that will help fans track the social activity of their team in social networks (Facebook, Twitter, Instagram).
It took another day.
Mom, mom, what will I do
In this action, the most difficult was to resist the temptation and at least every second sentence on the features to answer "no." Total, we said “no” about ten times - for example, user badges, registration and pre-moderation. And while this is not regretted.
A dozen "no" provided us with a few fat "yes": search by team and player, broadcast official accounts and posts of users by hashtags, a bit of statistics. We collected static information and went to work on the design.
Spent one day.
Here the fish was wrapped.
In this place we will take a pause - about the design, I suppose, not so interesting. We can only say that we focused on attractiveness and usability.
I wanted to attract the user with the design, and keep the content and convenience. It seems to work out .
The last thing I want to add before the intermission: we (honestly and honestly) did not cheat and did not touch the code before the start of the fight. The design was the last preparatory.
The prototype interface and design took two days.
Intermission
While you are standing in line for an espresso cap (with cognac, of course) and a caviar sandwich, we'll tell you a bit about our disposition before the fight. So, in our troupe there is one designer, one frontend and two developer backends. And the director manager is backstage.
Geography: Novokuznetsk, Tolyatti, Mariupol, Guadalajara (unexpected?). It was our trump card - after the start we were able to write code continuously for 48 hours. * the third bell rings *
Branch last
Speech technology
From the point of view of technology, we wanted to be on top. Have taken:
Ruby on Rails 4 ,
nginx + unicorn + capistrano
Postgres + redis
faye
coffeescript , ember.js
Clearly distributed the responsibilities of each in the team. Tons of work went on the backend, so the geographical location of the developers helped us a lot.
Difficulties were with a huge amount of data stored in 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 database is growing impetuously, and we have to withstand the load (and the habr effect too). The task is interesting.
To begin with, we decided to store user posts in Postgres. It’s not without redis, because the messages are streaming, it would be too wasteful to check every time whether this or that is in the database.
Redis organized a cache by id messages. SortedSet was used: due to the fact that the operation of adding and checking has log (n) complexity, we planned not to lose performance on this. Also, the priority parameter was the time to add. We did not want to keep all id records forever and therefore deleted posts with low priority (in our case, this is a measure of time).
The second moment of using redis (although it didn’t get to 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 visits the site, the front sends a request to the controller with the id of the entity that needs messages. And so he does every minute while the user views the page.
This lock is written to redis, where after about a minute it is deleted if a second request is not received. In the meantime, when creating messages, the hook that publishes on the faye checks with each attempt: if anyone is waiting for this message at all. And, if no one waits, skip this action.
Front, as we said, on ember.js. This turned out to be a great choice for a quick one-page application. However, due to the difficulties that arise even with a slight deviation from its ideology of web application development, after unsuccessful search for a solution, the interface had to be redone.
Marathon
It was difficult to adhere to the line of the party - minimalism. 48 hours is much less than required. And it was necessary to continue to limit themselves in their desires.
We did not have much time - for example, we were more involved in the code than in content for users. The problem we see is that, having entered the site, not everyone will quickly figure out why he is.
A curtain
Debriefing
We consider as a big omission the fact that we turned to face the judges and turned out to be a little half-turned towards the user. We have no descriptions of why our application is needed and how to use it - that is, there is practically no promotional content.
Not everyone in the front is perfect. We did not have time to hone the interfaces.
We did not have time to fully test the demons involved in collecting content from social networks. If problems arise, god, of course, restarts everything, but part of them is still not clear.
There was not enough time to add a real-time project to the faye, although everything was ready for this. As planned, the number of posts, subscribers and new posts had to be updated automatically, producing a wow-effect and causing a storm of applause.
But in general, we are pleased with the work done. And how workable and interesting the project we have turned out is up to you.
Afterword
I would like to wish good luck to all the teams from Russia.
Here is a list of those we found, for sure 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
Source: https://habr.com/ru/post/198426/
All Articles