This is the first in a forthcoming series on how I revived a once-gone history in code. In this article, I will describe the implementation of registration in terms of residence.
Background
For the first time I read about the Leningrad telephone broadcast in one fiction book. Then I started looking for information about this on the net. I was amazed and encouraged by how the bug led to such a unique socio-technical phenomenon. In fact, this is the first public chat, a social network, call it what you want, but just imagine what it was in the USSR! For that time and the social regime, it was something unimaginable.
What it is? If possible, simpler
There are many articles on this topic on the net, one , two , but I will try to explain it simply.
PBXs of that time had a bug - when calling certain non-existent numbers, people ended up in a group conversation, this is also called an audio conference or "Telephone broadcast". For that time, it was so cool and unusual that the topic went.
How did it end
Of course, there were attempts to take control of this, but these phenomena arose throughout the Union and this was problematic. But the time and modernization of the automatic telephone exchange made the "Telephony Ether" go down in history.
I want to revive some ideas
Because I'm also a
The result of my work was a symbiosis of the idea of "Telephone Ether", VoIP PBX Asterisk and Telegram.
If you are interested in getting a feel for how it works, use the link .
Registration implementation. City base
It is possible and even necessary to implement such bots with a minimum amount of data that users enter during registration. For example, in my bot, about 20% of users did not complete the registration process. I request all this data for future
features that will be implemented if there are more users, for example
- Airs by city, country, topic (for this, when registering, the user is asked to indicate his place of residence)
- Dating by filters (for this, when registering, the user is asked to indicate gender, age)
This data in the bot can be changed at any time through the settings menu, no one bothers to specify any value. I deliberately did not implement the definition of residence through the button send geolocation so as not to confuse users and preserve their anonymity.
In this article, I decided to share the most difficult moment of registration implementation - choosing a place of residence.
Ideally, to implement registration in terms of indicating the place of residence, you need to have a database of all cities in the world, which implies several problems:
- Find such a base or create it yourself.
It is not so easy to find such a database for free, it is even more difficult to create. - . .
- . .
- . 1,5 — 2 GB. , vps, ..
And in general, why store the cities of Zimbabwe if your content is intended for the CIS countries?
All databases that I did not go public did not satisfy any of the listed points.
So I
I decided to create the base myself. Also, make a mechanism for further filling in the automatic mode with data that is not in the database.
I read several articles about the telegram audience and decided to make an actual database in a semi-manual mode for the countries of Russia, Ukraine, Belarus, Uzbekistan and the USA.
How did I do it?
For the indicated countries, I took data from Wikipedia about large cities, saved it to a csv file and passed each value through the wonderful geopy library... The results were saved in a SQLite database.
I share the base with the community. I hope for someone it will save time.
The user has the opportunity to enter the place of residence with errors or using the old names of the settlements thanks to my use of the geopy library. I pass the data entered by the user through geopy, then check for the presence of the corresponding record in the database. If a record exists in the database, I assign the user an identifier of the settlement; if not, I write a new settlement to the database and, again, assign its identifier to the user.
Thus, I do not store a bunch of unnecessary settlements in the database.
In a simplified form, the algorithm for choosing a place of residence by a client during registration is as follows:
This is how my hybrid circuit turned out.
At the same time, on the hosting, the database occupies only 512 KB and is dynamically filled by the users themselves.