New clone or service in 24 hours

One fine evening (the day before yesterday) I and higher , tired of monotonous projects, decided to distract themselves from pressing matters and to do something interesting or new. “Startup!”, Laughing, we said in one voice. And what else do all those who are not lazy? :-) But since the main work is not going anywhere, it was decided to allocate no more than 24 hours to the project. If we did not meet - this article would not exist.

The result was ChatVdvoem .

How it was?

Since our goal was not to create a unique product, but only to test our strength and stretch our fingers, we, without further ado, ran through the latest articles of dear Habr and looked at the latest trends in the start-up movement. Having chosen the idea more attractively, they started the chronometers' hands on a long journey and opened their IDEs. The choice fell on omegle , which clones have already been announced here .
')
Let me remind you that the idea of ​​service is that you communicate with a randomly selected person, without knowing anything about him and completely anonymously. It is about the “fellow traveler syndrome” inherent in man, when he can discuss any topics with his fellow traveler, knowing that he will never see him again. Although, in case of interest, no one bothers you to exchange coordinates.

Since I am engaged in server design and programming, and higher html-layout and playing the piano, I had to take a load on a new area of ​​activity (I’m a client side, and a higher design). We didn’t make a prototype, didn’t write TK, didn’t delve into solutions. Providing further work and showing the results of the previous one, we intersected in jabber every 5-6 hours. Finally, after 23 hours and a half of continuous work, the result was uploaded to the hosting and the tests performed showed a satisfactory result.

From the moment of the idea to the final implementation, 24 hours have passed.

How this thing works

Communicating with the server takes place with the help of a rather popular technique of long polls . One of the goals of our action was, in practice, to try out some new, but wonderful tools. So for hanging requests dklab_multiplexor is used, its announcement was on Habré only four days ago. On the backend, Redis , a relatively new product, is used as a non-relational database and queuing system, but this is the third project where I successfully use it.

dklab_multiplexor on my Ubuntu wound up with a half-kick, but on the freebsd's server, dancing with a tambourine lasted a total of about eight hours. This does not mean that all this time I looked at the console, this is the total execution time of all processes on the server with my rare interventions. The main problem was that on Ubuntu there was perl v5.8.8 and on the server v5.8.9. So without having forced the utility to work, I had to perform a pearl downgrade, after which the problem was exhausted by itself.

At the moment, only the Opera with Opera browser under version 10 is alive. The fact is that it does not generate onunload or onbeforeunload events, and therefore, if your interlocutor left in English by clicking on the cross in the browser, you will not know about it and you will believe that he is still connected. But, anyway, we will solve this problem.

In general, if interest appears to the topic, I will describe with a separate topic how the full service works: the logic of queues, the solution of ambiguities (how atomic operations help), the fight against rejection of the chat at all stages, etc.

What's next

For a short period of work, a lot of ideas were born on how to significantly extend the functionality of the service without killing its main idea . If the product turns out to be at least slightly in demand, then it will be interesting to work on its functional enrichment :-)

I want to understand how much the multiplexor can withstand (and nginx proxying it, as well as my server).
I want to get feedback and error descriptions from sophisticated users.
And, finally, I want to share a feeling of deep satisfaction from the quality of the work performed, clamped in the time frame.

Chat together

Anton Isaikin, Dmitry Paputsa,
specifically for the Habrahabr project :-)