Telegram: Haqiqatan Ham Eng Xavfsiz Messengermi?

Ko‘pchiligimiz Telegramni dunyodagi eng xavfsiz messenjerlardan biri deb bilamiz. Lekin uning xavfsizlik mexanizmlariga biroz chuqurroq nazar tashlasak, bu savolning javobi unchalik ham oddiy emasligini ko‘ramiz.

Keling, avval “xavfsiz suhbat” deganda nima nazarda tutilishini aniqlashtirib olaylik. Dasturlash nuqtai nazaridan, bu "E2EE" (end-to-end encryption) tushunchasini anglatadi.

Bu jarayon qanday ishlaydi?

1. Siz xabarni yozasiz.
2. Xabar sizning telefoningizda shifrlanadi.
3. Bu shifrlangan xabar server orqali yuboriladi.
4. Faqatgina qabul qiluvchining telefoni uni shifrdan chiqarib, o‘qiy oladi.

E2EE usuldagi shaxsiy chatlarda gaplashsangiz, hech kim, hatto Durovni akasiyam serverlariga kirib xabarlaringizni o‘qiy olmaydi.

Lekin oddiy Telegram chatlari bunday ishlamaydi. Siz jo‘natgan xabar avvalo Telegram serverlariga boradi. U yerda xabar shifrlangan bo‘lsa-da, bu shifrlash (Client-Server Encryption) faqat sizning telefoningizdan servergacha amal qiladi. Serverda esa xabar qayta ishlanadi:

- Xabar bir necha qismga bo‘linadi (chunking).
- Bu qismlar va ularni ochish uchun kalitlar (decryption keys) turli davlatlardagi serverlarda saqlanadi.
- Qabul qiluvchiga yetib borgunicha, bu qismlar serverda qayta birlashtiriladi va keyingi telefonga jo‘natiladi (Server-Client Encryption).

Telegram bu usulni juda xavfsiz deb hisoblaydi, chunki xakker sizning xabaringizni o‘qish uchun turli mamlakatlardagi serverlardan ham xabar qismlarini, ham kalitlarni topib olishi kerak. Bu deyarli imkonsiz, ammo nazariy jihatdan imkoniyat mavjud. Bu sizning xabarlaringizni serverlarda o‘qib bo‘lmaydi degani emas - Telegramning o‘zida bu ma’lumotlarga kirish imkoniyati bor.

Haqiqiy Xavfsizlik - Mahfiy Chatlarda

Agar siz hech kim xabarlarimni o'qiy olmasin desangiz, Telegramning "maxfiy chat" funksiyasidan foydalanishingiz kerak.

Maxfiy chat nima qiladi?

Bu chatdagi barcha xabarlar sizning telefoningizda shifrlanadi (E2EE) va faqat qabul qiluvchi telefonida shifrdan chiqariladi. Shifrlash kalitlari serverda saqlanmaydi.

Bu funksiya faqat mobil ilovalar uchun mavjud, kompyuter (desktop) ilovalarida ishlamaydi. Shuningdek, maxfiy chatlarni guruhlar yoki kanallar uchun ishlatib bo‘lmaydi, shu sababdan guruhni nazorat qiladigan bot yasab qo'yib, oxirgi eventlarini olib ko'rsangiz "Rodnoylar AUEEEE" degan gruppadagi xabarlarni bemalol o'qib o'tirsangiz bo'ladi.

Oddiy kundalik muloqot uchun Telegramning odatiy chatlari yetarlicha xavfsiz. Juda maxfiy, shaxsiy yoki muhim ma’lumotlar almashmoqchi bo‘lsangiz, albatta "Maxfiy chat"dan foydalanganingiz ma’qul.

@mabrur_dev

Cursor sizlardayam narx hisoblamay qo'ydimi? Nimagadir, 1 haftadan beri bir tiyin ishlatganim yo'q, g'alati tuyulyapti )

Mikroservislardan monolitlarga qaytish tendensiyasi haqida ko'p o'qib qolayabman. Men ham tajribamdan kelib chiqib, shu mavzu bo'yicha ikki og'iz gaplarimni aytmoqchiman.

Nega ko'pchilik mikroservislardan voz kechib, monolitlarga qaytishni boshladi, nega bu hype avvalgidek emas?

1. Murakkablik Yo'qolmaydi, Faqat "Ko'chib O'tadi"

Mikroservislardagi ko'pchilik ishonadigan narsa - murakkablikni kamaytirish. Lekin bu shunchaki illyuziya. Dasturlashda "Conservation of Complexity" (Murakkablikning saqlanish qonuni) degan yozilmagan tushuncha bor. Ya'ni, siz murakkablikni yo'q qilmaysiz, shunchaki uni bir joydan ikkinchi joyga ko'chirasiz.

- Monolitdagi murakkablik: Kod ichida yashaydi. Modullar, klasslar va funksiyalar orasidagi bog'liqliklarda namoyon bo'ladi. Buni yengish uchun SOLID, DRY kabi dizayn prinsiplarini yaxshi bilish va ular bilan ishlash kerak bo'ladi. Kod ishlashi bitta asosan bitta joyda va tushunishga oson.

- Mikroservislardagi murakkablik: Endi bu murakkablik tarmoqqa ko'chadi. Siz nafaqat kod haqida, balki tarmoqning ishonchsizligi, ma'lumotlar bazasidagi taqsimlangan tranzaksiyalar (distributed transactions), service discovery, versiyalash va API shartnomalari kabi butun bir "distributed systems" muammolari haqida bosh qotirishingiz kerak.

2. "Yashirin Xarajat"

Dasturchilar mahsulot o'rniga infra bilan band va bu menimcha, mikroservislarning eng katta "yashirin xarajati". Har bir servis uchun alohida CI/CD pipeline, monitoring, logging, alerting va xavfsizlik konfiguratsiyalari kerak. Bu esa mahsulot rivojlanishidan vaqt oladigan ulkan DevOps ishini talab qiladi.

Amazon kabi gigantlarda har bir jamoaning ichida bunga mas'ul SRE (Site Reliability Engineer) mutaxassislari bor. Ammo kichikroq jamoalarda bu yuk ko'pincha dasturchining yelkasiga tushadi.

Natijada oddiy bir funksional uchun bir nechta servisni o'zgartirish, ular orasidagi API contractlar buzilmasligini ta'minlash va bir necha jamoa bilan kelishish kabi bosh og'riqlar paydo bo'ladi. Bu esa yana bir xavfli anti-pattern - "Distributed Monolith" (taqsimlangan monolit) ni keltirib chiqaradi. Servislar alohida deploy qilinsayam, ular bir-biriga shunchalik bog'liqki, bittasini o'zgartiish uchun qoglanlariniyam o'zgaritish kerak bo'ladi.

Davomi pastda...

3. Tushunarsiz Bounded Contexts

Mikroservislar qurishdagi eng og'riqli nuqtalardan biri - bu biznes domenini noto'g'ri boundariesga ajratish. O'zim ham bu yo'lda ko'p qoqilganman.

Domain-Driven Design (DDD) konsepsiyasi servislarni biznes qobiliyatlariga qarab ajratish kerakligini aytadi. Bu chegaralar "Bounded Contexts" (Chegaralangan Kontekstlar) deb ataladi. To'g'risini aytganda, bu tushunchani to'liq anglash va amalda to'g'ri qo'llash - arxitekturaning eng qiyin vazifalaridan biri. Agar kontekstlarni noto'g'ri aniqlasangiz, servislar o'rtasida tinimsiz "suhbat" (chatty communication) va o'ta kuchli bog'liqlik paydo bo'ladi.

Amazon Prime Video'ning monolitga qaytishining asosiy sabablaridan biri ham aynan shu: ular video monitoring servisining chegaralarini noto'g'ri aniqlagani sababli tarmoq xarajatlari osmonga chiqib ketgan.

4. Jamoa Tuzilmasi Arxitekturani Belgilaydi

Mikroservislar mustaqil, avtonom jamoalar uchun mo'ljallangan. Agar sizda 50 kishilik bitta katta jamoa bo'lsa-yu, siz ularni 15 ta mikroservis ustida ishlashga majburlasangiz, shaxsiy fikrimcha, kompaniya noto'g'ri yo'lda bo'ladi. Natijada doimiy sinxronizatsiya, cheksiz "call"lar, boshqa jamoa ruxsatini kutib bloklanib qolishlar kuzatiladi. Arxitekturani tanlashdan oldin berilishi kerak bo'lgan savol shu:
"Jamoalarimiz ham shunday "mikro" va mustaqil ishlay oladimi?"

5. Miya uchun Haddan Tashqari Yuklama (Cognitive Load)

Bitta monolitda dasturchi butun dastur mantig'ini bitta IDE ichida kuzatishi va debug qilishi mumkin. 15 ta mikroservisli tizimda esa bitta so'rov (request) qaysi servislardan o'tib, xatolik aynan qayerda yuz berganini tushunish uchun butun tizimning mental modelini miyada ushlab turish kerak. Bu kognitiv yuklamani keskin oshiradi va samaradorlikni tushiradi. Fokusni yo'qotdingizmi, demak, hammasini boshidan boshlashingiz kerak.

Mikroservislar Google yoki Netflix kabi gigantlarning muammolarini hal qilish uchun paydo bo'ldi. Ammo ko'pchilik hype'ga ergashib, bu yechimni o'zining mutlaqo boshqa muammolariga qo'llay boshladi. Natijada ular "mikroservis muammosi" deb ataladigan yangi va ancha qimmat muammoga duch kelishdi.

Hozirgi sog'lom trend - bu "Monolith First" tamoyiliga amal qilish. Ya'ni, dasturni yaxshi strukturalangan modular monolit bilan boshlab, faqat biznes va texnik zarurat tug'ilganda eng ko'p og'riq keltirayotgan modulni alohida servis sifatida ajratib olish

@mabrur_dev

Yana miyani ishlatamiz )

Tasavvur qiling, Payme yoki Click ishlatyapsiz. Ikkalasidayam QR Code orqali to'lov qilish imkoniyati bor. Istalgan to'lov tizimida necha hil QR Code bilan to'lash kombinatsiyalari bor deb o'ylaysiz?

Har bir turdagi QR Code qanday ishlaydi, ular statikmi yoki dinamik o'zgaradimi?

QR Code orqali to'lovlar asosan 2 xil bo'ladi, static va dinamik. Lekin ulardan yana 2 xil kombinatsiya yasasa bo'ladi: Consumer Presented, Merchant Presented

Texnik intervyularda beriladigan savollardan biri - API va SDK ning farqlari nimada?

Bu savolga qanday javob bergan bo'lardingiz?

Shtraflari sanoqsiz qaysidir brat, perevaldagi jarima bor yo’q ko’rsatadigan leddan programmasini o’chirvoripti shekili😂

AI Agent vs MCP: Aql va Mahorat jangi!

Sun'iy Idrok (AI) shunchaki savollarga javob beradigan suhbatdosh rolidan chiqib, allaqachon real vazifalarni bajara oladigan yordamchiga aylanib bo'ldi. Hozirgi kundagi AI yordamchilar evolyutsiyasi deganda, eng ko'p ikki xil turdagi muhim tushunchalar tarqalgan - AI Agent va MCP (Model Context Protocol). Xo'sh, MCP va AI Agentlar nima, ularning farqi nimada?

1. AI Agent: Sizning Shaxsiy Yordamchingiz.

Tasavvur qiling, sizda bir yordamchi bor. Siz unga "Brat, ertaga bir do'stim bilan uchrashuvim borda, nima qilsam bo'ladi?" deysiz. U esa o'zi internetga kiradi, kerakli saytlarni qidiradi, sizning qiziqishlaringizni, uning qiziqishlarini tekshiradi va sizga borish mumkin bo'lgan kinolar, parklar va boshqa narsalarni tayyor reja qilib beradi. AI Agent - huddi shunday yordamchi.

Rasmda ko'rsatilganidek, AI Agentning asosiy xususiyatlari quyidagilar:

- Avtonomlik: Agentga vazifa berganingizdan so'ng, u doimiy inson nazoratisiz mustaqil harakat qila oladi. U o'z rejasini tuzadi va uni amalga oshiradi. Shu bilan birga, "Human Control" (inson nazorati) ham aralashib turishi mumkin, ya'ni siz istagan paytda jarayonga aralashib, yo'nalish bera olasiz.

- Xotira (Memory): Agent shunchaki bir martalik buyruqni bajarmaydi. U oldingi suhbatlarni sizning xohishlaringizni va to'plagan bilimlarini xotirasida saqlaydi. Bu unga sizni yaxshi tushunishga va kelajakdagi vazifalarni yanada yaxshiroq bajarishga yordam bera oladi.

- Tools: Bu uning super kuchi desak bo'ladi. Agent shunchaki rejalashtirish bilan cheklanmaydi. U real dunyo bilan ishlash uchun turli toolardan foydalanadi:

APIga Callar: Boshqa dasturlar va servislar bilan gaplasha oladi.
Internetga kirish: Ma'lumot qidiradi, yangiliklarni o'qiydi.
Kod bilan ishlash: Kod yozishi, tahlil qilish va ishga tushirishi mumkin.

- Reactivity: Agent o'zining "atrof-muhiti" (masalan, yangi kelgan email, tizimdagi o'zgarishlarni) kuzatib boradi va shunga yarasha o'z harakatlarini o'zgartirishi mumkin.

Xulosa: AI Agent - bu shunchaki suhbatlashadigan model emas, bu aniq maqsadlar qo'ya oladigan, reja tuzadaigan, xotiraga ega va o'z toolaridan foydalanib mustaqil ishlaydigan bir tizim.

2. MCP: Tizimlar uchun "Universal Adapter"

Endi tasavvur qiling, siz Xitoyga sayohatga bordingiz. Telefoningiz zaryadkasi O'zbekistondagi rozetkalarga tushadi, ammo Xitoynikiga to'g'ri kelmaydi. Sizga nima kerak? "Universal adapter"

MCP (Model Context Protocol) - Sun'iy Idrok uchun huddi shunday universal adapter.

Anthropic kompaniyasi tomonidan ishlab chiqilgan bu tizim - AI modellar (masalan Claude bilan) tashqi dunyodagi turli tizimlar (database, fayl storagelar, APIlar) bilan oson til topishish uchun chiqarilgan standart (protokol).

Rasmning pastki qismida uning ishlash prinsipi ko'rsatilgan:

- Host: Bu siz foydalanyotgan dastur - masalan, Claudening desktop ilovasi, kod muharriri (IDE) yoki boshqa bir AI vositasi.

- MCP Client (Mijoz): Bu AI modelining ichiga o'rnatilgan komponent. U modelning "istaklarini" MCP tiliga o'girib beradi.

- MCP Server: Bu eng asosiy qismi. U modeldan kelgan so'rovni qabul qiladi va uni kerakli tashqi tizimga (masalan Google Drive, PostgreSQL, Githubga) yo'naltiradi. Natijani esa yana modelga tushunarli tilda qaytarib beradi.

MCP bo'lmasa dasturchilar har bir yangi tizim (masalan Slackga integratsiya uchun) alohida maxsus kod yozishlari kerak bo'lardi. MCP esa yagona stadartlarni yaratib, bu jarayonni osonlashtirib berdi. Bitta "adapter" bilan xar-hil rozetkalarga ulanish imkoniyatini berdi.

Oddiyroq aytganda, AI Agent – bu usta oshpaz. MCP esa – barcha oshxona anjomlarini (plita, muzlatgich, mikserlarni) yagona standartdagi elektr tarmog'iga ulanishini ta'minlaydigan tizim. Oshpaz (Agent) har bir anjom uchun alohida "tok manbai" qidirib yurmaydi, shunchaki rozetkaga ulaydi va ular ishini qiladi. Demak, AI Agent o'z vazifalarini bajarish uchun MCP protokollardan foydalanishi mumkin.

@mabrur_dev

Ma'lumotlar qayerda keshlanadi? Caching turlari

1. Client-side Cache (Mijoz tomonidagi kesh)

Bu kesh eng ko'p ishlatiladigan qatlamlardan biri. U sizning brauzeringizda yoki mobil ilovangizda joylashadi.

Qanday ishlaydi? Siz birinchi marta veb-saytga kirganingizda, serverdan kelgan ma'lumotlar (HTTP javoblari) maxsus "expiration date" bilan birga kompyuteringizga saqlanadi. Keyingi safar o'sha sahifani ochganingizda, brauzer avval keshini tekshiradi. Agar ma'lumot eskirgan bo'lmasa, uni serverga so'rov yubormasdan yuklaydi.

2. CDN (Content Delivery Network)

CDN - bu dunyoning turli nuqtalarida joylashgan serverlar tarmog'i. Asosan statik resurslarni (rasm, video, skriptlar) keshlash uchun xizmat qiladi.

Qanday ishlaydi? Foydalanuvchiga resurslar geografik jihatdan unga eng yaqin serverdan yetkazib beriladi. Bu esa ma'lumot yuklanish vaqtini (latency) kamaytiradi.

3. Load Balancer

Load Balancer ning asosiy vazifasi - kiruvchi so'rovlarni bir nechta serverlar o'rtasida taqsimlash. Ammo u ham keshlovchi vazifasini bajarishi mumkin.

Agar minglab foydalanuvchilar bir xil so'rovni (masalan, "bugungi yangiliklar") yuborayotgan bo'lsa, Load Balancer bu so'rovga javobni o'zida keshlashi va ortdagi serverlarni bezovta qilmasdan foydalanuvchilarga qaytarishi mumkin.

4. Message Broker (Kafka)

Kafka kabi tizimlar odatiy cachinglar uchun emas, lekin ma'lumotlarni vaqtinchalik saqlash orqali kesh vazifasini bajara oladi.

Qanday ishlaydi? Xabarlar (masalan, foydalanuvchidan kelgan eventlar) avval Kafka klasterlaridagi disklarga yoziladi. Consumer servislar esa bu xabarlarni o'zlariga qulay vaqtda o'qib oladi. Ma'lumotlarda retention policy bo'ladi va shu sozlamaga qarab bir necha kun davomida saqlanib turishi mumkin. Bu usul murakkab tizimlardagi qismlar o'rtasidagi bog'liqlikni kamaytiradi.

5. Services (Servislar ichidagi kesh)

Har bir microservice yoki dasturning o'zi ham bir necha darajali keshlashga ega.

CPU Cache (L1, L2, L3): Eng tezkor kesh. Protsessorning ichida joylashgan, eng ko'p ishlatiladigan mashina buyruqlarini saqlaydi.
RAM Cache: Protsessor keshidan sekinroq, lekin diskdan ancha tez ishlaydigan tezkor xotira. Asosiy ma'lumotlar ko'proq shu yerda saqlanadi.
Disk Cache: Ma'lumotlar qattiq diskda saqlanadi. Bu RAMdan sekinroq, lekin masofadagi ma'lumotlar bazasiga murojaat qilishdan tezroq.

6. Distributed Cache (Redis)

Redis kabi in-memory (xotirada ishlovchi) keshlar bir nechta servislar uchun umumiy bo'lgan markazlashgan kesh tuzish imkonini beradi.

Ma'lumotlar key-value ko'rinishida RAMda saqlanadi. Bu esa dbga nisbatan o'qish/yozish operatsiyalarini ancha tezlashtiradi.

7. Full-text Search (Elasticsearch)

Elasticsearch kabi tizimlar ma'lumotlarning bir nusxasini olib, ularni qidiruv uchun optimallashtirilgan maxsus indekslarga joylaydi. Bu ham o'ziga xos kesh hisoblanadi.

Qanday ishlaydi? Ma'lumotlar bazasida LIKE '%matn%' so'rovi bilan qidirish juda sekin ishlaydi. Elasticsearch esa oldindan indekslangan ma'lumotlar tufayli murakkab matnli qidiruvlarni juda tez amalga oshiradi.
Misol: Internet-do'kondagi mahsulotlarni nomi yoki tavsifi bo'yicha qidirish, log fayllarini tahlil qilish.

8. Database (Ma'lumotlar bazasi)

Hatto ma'lumotlar bazasining o'zi ham ishlashni tezlashtirish uchun bir nechta kesh mexanizmlaridan foydalanadi.

WAL (Write-ahead Log): O'zgarishlar asosiy ma'lumotlar fayliga yozilishidan oldin shu logga yoziladi. Bu tizim ishdan chiqqanda ma'lumotlar yo'qolmasligini ta'minlaydi.
Bufferpool: Databaseda RAMda o'zi uchun ajratilgan maxsus joy, eng ko'p so'raladigan ma'lumotlarni (jadvallar, indekslar) shu yerda saqlaydi.
Materialized View: Murakkab va ko'p resurs talab qiladigan so'rovlar natijasi oldindan hisoblanib, alohida jadval sifatida saqlanadi. Bu esa har safar so'rovni qayta ishga tushirishni oldini oladi.
Transaction Log, Replication Log: Bular tranzaksiyalar va ma'lumotlar nusxalari (replicas) o'rtasidagi sinxronizatsiya holatini qayd etib borish uchun xizmat qiladi.

@mabrur_dev

Juda yaxshi va tushunarli yozilgan CV ekan. Bunaqa turdagi CV lar ATS lardanam muammosiz o’tib ketadi, recruiter va texnik insonlar maza qilib o’qiydi

O’zimniyam CVin shunga o’xshash formatda.

@mabrur_dev

Крупнейший взлом NPM:

https://www.cyberkendra.com/2025/09/npm-packages-supply-chain-attack.html

https://github.com/chalk/chalk/issues/656

Название - Миллионов скачиваний в неделю
ansi-styles - 371
debug - 358
chalk - 300
supports-color- 287
strip-ansi - 261
ansi-regex - 244
wrap-ansi - 198
color-convert - 194
color-name - 192
is-arrayish - 74
slice-ansi - 60
error-ex - 47
color-string - 28
simple-swizzle - 26
supports-hyperlinks - 19
has-ansi - 12
chalk-template - 4
backslash - 0.3

Men ko'rgan eng zo'r webapplardan biri

https://posthog.com/

🚨 BECOME A SPEAKER AT THE UPCOMING DEVFEST TASHKENT '25!

We are thrilled to share some big news - DevFest is coming to Tashkent this November once again, and our Call for Speakers is now open!

Whether you are a developer building cool products, a product manager driving ideas to life, a designer crafting seamless experiences, or a founder pushing bold innovations - if you live and breathe tech, the stage is yours.

This is your chance to inspire others, exchange ideas, and showcase your expertise at one of the largest developer conferences in Central Asia.

You can join DevFest speakers lineup by giving:
🎙️ A 30-minute talk to spark ideas;
👨‍🏫 A 2-hour workshop to dive deep.

Submit your application to become a speaker here:
⏭️ https://sessionize.com/gdg-devfest-2025-tashkent/

Give back to community. Share your experience at DevFest Tashkent 2025!

@gdgtashkent