Telegram botlar qanday ishlashini tushunish uchun polling, webhook nima,
ular nega kerak kabi savollarga javob topsak.

User telegramda botga biror buyruq yuborganda, unga javob qaytishi uchun bu buyruq biz yozgan kodimiz turgan servergacha yetib kelishi kerak va server unga javob qaytarishi kerak. User yuborgan buyruqlar telegramning serveriga borib tushadi. Endi o'sha serverga kelgan buyruqlarni bizning serverimizga yetkazish kerak. Lekin telegram aynan o'sha bot uchun yozilgan bizning kodimiz qayerda turganini qanday biladi?

Telegram botlar uchun HTTP protocolidan foydalanadi. Muammo shundaki, HTTP bir tomonlama ishlaydi(push/promisedan tashqari). Ya'ni faqat bir tomon(client) request yuboradi, ikkinchi taraf(server) uni qabul qilib, response qaytaradi.
Bu degani, server xohlagan paytida clientga response yubora olmaydi. Faqatgina client request yuborgandan keyingina response yuborish mumkin.

Bizning server bilan telegram server orasida ma'lumot almashishning ikki yo'li bor:
1. Bizning server HTTP client, telegram serveri esa HTTP server vazifasini bajaradi.
2. Telegram serveri HTTP client, bizning server esa HTTP server vazifasini bajaradi.


1. Deylik, user telegram botga biror buyruq yubordi. Telegram serveri bu buyruqni to'g'ridan to'g'ri bizning serverga yubora olmaydi. Sababi, yuqorida kelishganimizdek, faqat client birinchi bo'lib ma'lumot yubora oladi. Telegram server esa hozir HTTP server rolini o'ynayapti. Plus, telegram biz qaysi bot haqida so'rayotganimizni ham bilmaydi. Demak, avval client so'rov yuborishi kerak.
Lekin client qachon so'rov yuborish kerakligini(telegramga yangi buyruq kelganini) qanday biladi?
Javob — hech qanday. Shunchaki ma'lum vaqt oraligi bilan telegram serveriga to'xtovsiz request yuborib turadi. Botga yangi buyruq kelsa, telegram keyingi safar bizning serverdan request kelganda uni response qilib yuboradi. Bu taxminan mana bunday bo'ladi:

Client: Falonchi bot uchun yangi buyruq bormi?
Telegram: Yo'q
*ozgina vaqt o'tgach*
C: Bormi?
T: Yo'q
C: Bormi?
T: Ha, mana, ol. *Buyruqni yuboradi*
C: *Buyruqqa javob qaytarib, request shaklida yuboradi*
T: Oldim.
C: Bormi?
T: Yo'q
...

Mana shu usul, ya'ni bizning server ma'lum vaqt oralig'i bilan to'xtovsiz telegramdan so'rab turishi polling deyiladi.


2. Endi bizning server HTTP server vazifasini bajarib, Telegram serveri HTTP client rolini o'ynab beradi. Endi telegram client sifatida buyruqlarni to'g'ridan-to'g'ri bizga yubora oladi. Lekin buning uchun ikkita shart bajarilishi kerak:
1. Telegram bizning serverning manzilini bilishi.
2. Bizning server web server sifatida ishlashi, ya'ni requestlarni qabul qilishi kerak.

Buning uchun boshda Pashka akaning serverlariga "Falonchi botga kelgan buyruqlarning hammasini falonchi adressdagi serverga request qilib yubor" degan ma'noda xabar berib qo'yamiz. O'zimizning serverimizni esa web serverga aylantiramiz.

Endi faqat yangi buyruq kelgandagina telegram bizning serverimizga request yuboradi:

Telegram: Uka, botingga yangi buyruq keldi. Ma, ol.
Bizning server: *qayta ishlab, natijani yuboradi*.
*keyingi safar buyruq kelganda*
Telegram: Yangi buyruq. Ma, ol.
...

Mana bu usul, yani telegram bizning serverga request yuborishi esa webhook deyiladi.

JR:
Mikroservislar yomon. Ular boshqa yaxshiroq variant yo'qligi uchun ishlatilayapti.

Men:
Shu "boshqa yaxshiroq variant yo'qligi sabab" degan joyini "an'anaviy variantlar (ba'zi vaziyatlarda) ish bermagani sabab" ga o'zgartirsak, qiziq narsalar chiqadi:

Mikroservislar nega yaratildi?
An'anaviy variantlar(monolith) ish bermay qolgani sabab.

O'zi komputerlar nega yaratildi?
An'anaviy hisoblash usullari ish bermay qolgani sabab.

Miltiq nega yaratildi?
An'anaviy usullar(qilich) ish bermay qolgani sabab.

G'ildirak nega yaratildi?
An'anaviy usullar(sudrash) ish bermay qolgani sabab.

Ana shunaqa gaplar...

P.S. Bunaqa faylasufona gaplar qayerdan keldi, bilmayman😁

Toshkentda ish izlayotgan tanishlar bo'lsa, "fisht" deb qo'yinglar.

Newmax Technologies - это холдинг продуктовых IT компаний с такими проектами как My Taxi, Express 24, Workly, Max Track в поисках Junior Back-end разработчика на проект My Taxi.

Мы ищем специалиста, желающего развиваться в направлении Back-end разработки. Если вам интересно создавать программное обеспечение, работая с базой данных, архитектурой, программной логикой — смело откликайтесь на вакансию.

Обязанности:
- Создание нового функционала и оптимизация работы уже имеющегося;
- Повышение надежности и качества системы на всех уровнях.

Требования:
- Знание Python (Django);
- Понимание принципов RESTful API/gRPC, Microservices;
- БД MySQL, миграции;
- Опыт работы с git;
- Свободное владение русским языком, английским на уровне чтения технической документации;
- Большим плюсом будут DevOps навыки, опыт работы с API платёжных систем.

Условия:
- Официальное трудоустройство по ТК РУз;
- График работы 5/2, 09:00-18:00;
- Офис в центре города (парк Бобура, Ракат махаля, ТРЦ Next);
- Заработная плата от 2 000 000 в зависимости от квалификации
- Контактное лицо: @alishermusurmonov

👉 @uzpythonjobs

Ba'zi kanal kuzatuvchilari nimaga postlar kamayib qolgani haqida so'rashayapti.
Sababi oddiy. Ko'p post bo'lishi uchun ko'p qiziqarli savol kerak. Savollar esa asosan communitydan keladi. Communityda faol bo'lish uchun esa yetarlicha bo'sh vaqt kerak. Ana shu vaqt hozir menda muammo. Lekin shaxsiyda berilayotgan savollarga maksimal javob berishga harakat qilayapman.

Shunaqa savollar bo'ladi-ki, u savollarga javob topish orqali ko'p narsa o'rganmasligingiz mumkin, lekin hali o'rganishingiz kerak bo'lgan ko'p narsani bilib olasiz.
Hozir bir fikr kelib qoldi. Vaqti-vaqti bilan kanalda #yaxshi_savol tagi bilan savollar joylab turaman. Lekin javob bermayman.
Hamma commentda o'z javobini qoldirishi mumkin (batafsil va hammaga tushunarli formatda bo'lsa juda yaxshi).
Kuzatuvchilar (hozircha) ko'p bo'lmasa ham orangizda kattagina xalqaro kompaniyalarda ishlaydigan dasturchilar bor.
Sizlardan o'z bilimingizni commentlarda ulashishingizni so'rab qolardim. Bu endi boshlaganlar uchun foydali bo'ladi deb o'ylayman.

Boshladik, inshaalloh.

#yaxshi_savol

Avval web development yaxlit bitta soha edi. Keyin ikki asosiy qism: frontend va backendga ajraldi. Qizig'i, aslida bu qismlar abstrakt emas, nisbiy. Biz biladigan frontend va backend butun boshli web applicationga nisbatan olingan.
Web applicationning bir qismi uchun ham frontend va backend qismlari bor. Masalan, backend web serverning frontend qismi bu API.

Endi savol.
Biz biladigan web backendning o'zi uchun ham backend qismi bor. Bu nimaligini ko'pchilik biladi. Qizig'i, o'sha qismning ham frontend va backend qismlari bor.
Siz kommentlarda shu backend, ya'ni web backendning backend qismining backend qismi nimaligini ayting.
Iloji bo'lsa, batafsilroq javob qoldiring. U nima, nega kerak, qanday ishlaydi, qanday turlari bor va hokazo.

P.S. Tanishlarga ham share qilsangiz xursand bo'lardim.

#yaxshi_savol

PostgreSQL bilan ishlaganda, deylik siz bir ma'lumotni UPDATE yoki DELETE qildingiz.
Lekin shu vaqtning o'zida eski qiymat ham tabledan o'chib ketmaydi.

Masalan, sizda
id INT, name VARCHAR
columnlaridan iborat persons table bor.
Deylik, unda 1 ta row: (1, 'John') bor.
Keyin siz uni yangiladingiz:
UPDATE persons
SET name = 'Doe'
WHERE id = 1;

Yoki o'chirib yubordingiz:
DELETE FROM persons
WHERE id = 1;

Lekin ikki holda ham eski qiymat, ya'ni (1, 'John') xotiradan o'sha vaqtning o'zida o'chib ketmaydi.

Savol: Eski qiymatlarni xotirada vaqtinchalik saqlab qolish nima uchun kerak va buning qanday negativ natijalari bo'lishi mumkin?

Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

#yaxshi_savol

Serverga kelayotgan requestlarni bitta web application instance ko'tara olmay qolganda load balancingga ehtiyoj tug'iladi.
Oddiy tushuntirganda, hamma requestni bitta instancega yuborish o'rniga, bir qancha instancelar ishga tushirib, requestlarni ularning orasida taqsimlab berish.

Load balancingning ham turlari bor.
Backend developmentda eng keng tarqalganlari layer 7 va layer 4 load balancing. Ya'ni, OSI modelining yettinchi (application) va to'rtinchi (transport) qavatida turib taqsimlash.

Savol: L7 va L4 load balancerlarning har birining qanday yaxshi va yomon taraflari bor?

Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

Maqola yozish uchun yaxshi mavzular o'ylab yuribman, lekin vaqt ajratish muammo bo'layapti.
Inshaalloh, yaqin kunlarda database bo'yicha yangi maqola chiqadi.

Yaxshi maqola ekan, vaqt topib o'qib chiqsangiz, eng kamida hali Pythondagi ko'p narsadan xabaringiz yo'qligini tushunasiz ))

https://realpython.com/python-memory-management/

#question
What are prefetch_related() and select_related() in django querysets and how they work?

Well, most of the time you wanna retrieve data from more than one table. In that case, you need an efficient way to play with more than just one model.

Let's say you have a Book model that has a ForeignKey relationship to Author model. You wanna get information about all books and their authors in a single view.

Let's say you have n books. You'll get all Book objects with a single DB query via Book.objects.all() queryset.
But each time you ask for the author of a book, django makes another DB query to retrieve information about the author of this book. In total, django performs n+1 queries: 1 query to get all the books and n queries to get authors of n books. This is what they call n+1 problem.

This is where prefetch_related() and select_related() come into the picture.
They have different purposes and they work differently.

1. select_related() simply makes a SQL JOIN for each selected relationship in a model. In simple words, you'll get data from multiple tables within a single query. For the example above, it joins the author table to the book table with book.author_id = author.id condition.
Instead of n+1 queries, you'll make 1 complex query to retrieve all the necessary data.
select_related() is limited to a single relationship level. This means, it can be used for first-level one-to-one and many-to-one relationships. If you have this kinda relationship:
Book -> Author -> User,
You cannot get data in User model from Book, because they don't have a direct relationship between them.

2. prefetch_related() is designed for more than 1 level relationship (like Author, Book, User example). Since it's not a direct relationship, you cannot make a SQL JOIN here. What prefetch_related() does is simply doing a separate query for each relationship, but all in a single batch.
You might be wondering then how it could be different from the usual way, if still it makes a separate query for each relationship. For example, if you loop through all the books and access to its author, django makes a query at the moment where you ask for it, which kills the performance. On the other hand, a queryset using prefetch_related fetches all the necessary data when you ask for all the books and author will be already there when you ask for them.
Since many-to-many relationship is technically combination of 2 foreignkeys, you cannot use select_related() with them. Here what you need is prefetch_related().

Mana haqiqiy daraja o'rtoqlar.
Dasturlashni kasb emas, san'at deb qabul qiladiganlarni ko'rsam maza qilaman ))
https://youtu.be/k13LpTPdxt4?t=767

Life of a DNS query
https://redd.it/scxe9z

by @programmer_humor

Netflixning backend arxitekturasini ko'rgandim, juda aqlli ishlab chiqilgan.
Hozir esa frontend qismini ko'rib yana bir marta qoyil qoldim.
Inshaalloh, bir kun kelib Netflixda ishlashni niyat qildim.

Ko'rib chiqishni tavsiya qilaman:
https://youtu.be/MxFt3YsjyQg

[Meme] No Title needed...
https://redd.it/swtznj

by @programmer_humor

Manetta "kotta bollani" o'yini boshlanayapti. Kuzatamiz.

P.S. O'zbekiston ham CIS davlatlariga kiradi.

#savol

database_sync_to_async(Profile.objects.get)(user=user)

Nega user=user ni get dan tashqarida yozildi?