How to stop worrying and create a team

    At the very end of the year, I was invited to participate in the creation of a very interesting project, at the intersection of video and sociality. Of the requirements was “necessary” and minimal input data. Of course, I immediately agreed, because it is very interesting to participate in something ambitious, especially when you yourself can influence what it eventually becomes.

    Remembering the theory of projects and applying it to our reality, my supervisor and I developed the following steps:

    1. Collecting and inventing functionality
    2. Architecture Creation
    3. Team search
    4. UX creation
    5. Design creation
    6. Development
    7. Deployment and Launch

    The first two stages went like clockwork - the benefit of imagination and experience is not to occupy with us. The third stage was more difficult - after all, good ones, and it’s just difficult to find specialists now.
    At the fourth stage, we slowed down - it turns out that we did not take into account all the stakeholders, and, as it turned out, each of them has their own ideas about UX.

    So, there is architecture, there is a new team, but there is no UX. Dead end. What to do?
    Naturally make another project!

    So that the resources do not stand idle, and so that the new team works together , we decided to make another project with close functionality - .

    Vsevideo is an aggregator of films from online cinemas (now). Future plans also to aggregate series and online broadcasts.

    The idea was quite simple - there are a lot of interesting and different films, here are a lot of online cinemas in which you can watch these films quite legally. The problem is that in different cinemas there is a different set of films, in some cinemas you can watch a movie for free, but with advertising, and in another cinema for 49, but without advertising.
    Well, plus, I would like to have my own base of watched films, as well as share this with friends.

    The idea, of course, is not original, but we did not find a worthy implementation. Therefore, as has happened many times on this planet, we decided to do everything ourselves.

    They decided to conduct the development according to the “API-First” principle. That is, we first developed the API documentation and implemented it.

    I have long been a fan of this approach and try to apply it in all my projects. In our age of multi-screen, a user can access a service from completely different devices and applications, and this particular one allows to separate the logic and presentation as much as possible. Moreover, the development of an additional user interaction point (interface) is easier than easy - here is the description of the API, take the design and make the application.
    Following this principle, the web interface is also a normal application, along with mobile and others, but more on that below.

    So, we took Django, installed the Django Rest Framework and implemented the API of our service. As a DBMS, we decided to use PostgreSQL.
    And here our first mistake became clear - do not use Django to implement a bare API. In fact, we use a maximum of 10% of the features of Django, and in the Django Rest Framework we were unable to cram what was in our documentation.
    Unfortunately, there simply was not time left to fix something.

    Since in our concept the web interface is a separate application, we decided to do it on NodeJS using Jade templates.
    Several of our mistakes turned out here: firstly, chasing requests through HTTP between the API server and the web server is very expensive; secondly, compiling jade templates is not very fast.

    We decided the first mistake simply - instead of HTTP we began to use ZeroRPC. A bonus came and the possibility of balancing.
    We solved the second error on the forehead - the usual caching in memcached. It turned out that the pre-compilation of Jade templates is not always possible in the current implementation, so for our new project we will fork, in which there will be this much-needed feature.

    The lion's share of bugs during the implementation was taken over by cinema robots parsers. Why it happened, we are still analyzing :-)

    Since we have the 21st century, a fairly powerful frontend has been written for the service. I won’t tell boring details, I’ll only notice that there are more than 1300 lines in the main CoffeeScript frontend file.

    Here's what we got under the hood:

    And here is what we got outside :

    So, what did we get as a result:

    Firstly, in our opinion, an interesting and useful service. Of course, there is still a lot of work to be done, a lot of things are buggy, but this is only a matter of time.
    Secondly, we tested several of our technical theories and found the best solutions that we will definitely use in future projects.
    Thirdly, and most importantly, we got an established team in which everyone knows the strengths of the other participants. Moreover, the entire team has increased useful experience and knowledge.

    Now I am absolutely sure that the best way to work out a new team is to implement a small project. For example, such as AllVideo .

    Also popular now: