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

Ozroq memlashamiz )

Responsive o‘rniga hamma joyga !important qo‘yadigan kelin

Merge conflictni hal qila olmaydigan kelin

TypeScriptdan qo‘rqadigan kelin

env faylini gitga push qilib yuborgan kelin

Light mode’da VS Code ishlatadigan kelin

Qolganini izohlarda davom etamiz...😅

Bit.ly qanday ishlaydi? System Design intervyularidagi klassik savolini birga yechamiz

Biz har kuni bit.ly, tinyurl, cuttly kabi qisqa havolalarga duch kelamiz. Ular uzun va xunuk URL manzillarni chiroyli va qisqa ko‘rinishga keltiradi. Lekin kapot ostida bu oddiy vosita qanday ishlashini hech o‘ylab ko‘rganmisiz?

Bu nafaqat qiziqarli masala, balki bir qator kabi yirik kompaniyalarning System Design suhbatlarida eng ko‘p beriladigan savollardan biridir.

Keling, tasavvur qilamiz: bizga shunday servisni noldan qurish vazifasi topshirildi. Buni qanday amalga oshiramiz?

1-qadam: Talablar va Cheklovlarni aniqlash (Requirements)

Har qanday tizimni loyihalashdan avval, uning funksional va nofunksional talablarini aniqlab olishimiz kerak.

Funksional talablar:

Foydalanuvchi uzun URL manzilni kiritib, unga mos qisqa URL olishi kerak.

Foydalanuvchi qisqa URL manziliga kirganda, u avtomatik tarzda asl uzun manzilga yo‘naltirilishi (redirect) kerak.

Nofunksional talablar:

High Availability: Tizim doim o'chib qolmasligi, limit tugamasligi, buzilmasligi kerak.

Tezkor (Low Latency): Manzilga yo‘naltirish jarayoni deyarli bir zumda amalga oshishi kerak.

Scalibility: Tizim milliardlab havolalarni va ularga bo'ladigan milliardlab murojaatlarni bajara olishi kerak.

Noyoblik (Uniqueness): Har bir qisqa havola faqat bitta asl havolaga bog'langan bo'lishi shart.

2-qadam: API dizayni (API Endpoints)

Tizimimiz bilan tashqi dunyo qanday "gaplashishini" belgilab olamiz. Buning uchun ikkita asosiy endpoint kerak bo'ladi:

1. Havolani qisqartirish uchun:

POST /api/v1/shorten

So'rov (Request Body):

{
  "original_url": "https://uz.wikipedia.org/wiki/Amir_Temur_maqbarasi"
}

Muvaffaqiyatli Javob (201 Created):

{
  "short_url": "https://short.uz/GorAmir"
}

2. Qisqa havoladan asl manzilga yo'naltirish uchun:

GET /{short_code}

Misol: Foydalanuvchi https://short.uz/GorAmir manziliga kiradi. Bu yerda GorAmir — bu bizning short_code.

Javob: Tizim 301 Moved Permanently HTTP status kodi bilan javob qaytaradi. Bu javobning Location header qismida asl uzun URL (https://uz.wikipedia.org/wiki/Amir_Temur_maqbarasi) bo'ladi. Brauzer bu javobni olgach, foydalanuvchini avtomatik tarzda o'sha manzilga yo'naltiradi.

3-qadam: Ma'lumotlar bazasi sxemasi (Database Schema)

Endi ma'lumotlarni qanday saqlashni o'ylab ko'ramiz. Bizga oddiy, lekin samarali jadval kerak. Keling, uni urls deb nomlaymiz. Unda id, original_url, short_code, created_at kabi fieldlar bo'ladi.

4-qadam: Qisqa kodni generatsiya qilish (short_code Generation)

Bu — tizimning eng qiziqarli va muhim qismi. short_code qanday yaratiladi?

Yomon yondashuv: Hashing (masalan, MD5)
Uzun URL'ni MD5 orqali hashlab, natijaning birinchi 6-7 belgisini olish mumkin.

Muammo: To'qnashuv (Collision). Ikki xil uzun URL bir xil qisqa kodga ega bo'lib qolishi ehtimoli bor. Bu esa mutlaqo yaroqsiz yechim.

Yaxshi yondashuv: Base62 Encoding
Bu ancha universal standart hisoblanadi va quyidagicha ishlaydi:

Yangi URL bazaga saqlanganda, unga unique, avtomatik o'suvchi id beriladi (masalan, 1001). Bu raqam 10 lik sanoq tizimida.

Biz bu id raqamini Base62 sanoq tizimiga o'tkazamiz. Nega aynan Base62? Chunki u URL uchun xavfsiz bo'lgan 62 ta belgidan foydalanadi: [0-9], [a-z], [A-Z].

Bu usul collisionlarni oldini 100% oladi, chunki har bir id noyob.

Misol:
id = 1 -> 1 (Base62)
id = 1000 -> gE (Base62)
id = 99999999 -> 15FTGf (Base62)

Ko'rib turganingizdek, hatto 100 millioninchi havola uchun ham kod juda qisqa (6 belgi) chiqadi.

Davomi pastda...

5-qadam: Katta yuklamalarga bardosh berish (Scaling)

Endi tizimni milliardlab so'rovlarga tayyorlaymiz.

Taxminiy hisob-kitob:

Yozish (Write): Oyiga 100 million yangi URL.

O'qish (Read): Odatda, o'qish operatsiyalari yozishdan ancha ko'p bo'ladi. Aytaylik, 10:1 nisbatda. Demak, oyiga 1 milliard redirect.

Bu soniyasiga ~40 ta yozish va ~400 ta o'qish degani. Bu juda katta yuklama!

Qayerda muammo bo'ladi? Asosiy yuklama ma'lumotlar bazasining o'qish operatsiyalariga tushadi.

Yechim №1: KESHLASH (Caching!)
Bu eng muhim optimizatsiya. Biz Redis kabi in-memory keshdan foydalansak bo'ladi.

Mantiq: Foydalanuvchi GET /GorAmir so'rovini yuborganda:

Tizim avval Redis keshidan GorAmir kalitini qidiradi.

Cache Hit (Keshdan topildi): Agar kalit topilsa, unga mos uzun URL keshdan olinadi va foydalanuvchiga bir zumda qaytariladi. Ma'lumotlar bazasiga umuman murojaat qilinmaydi!

Cache Miss (Keshda yo'q): Agar kalit topilmasa, tizim ma'lumotlar bazasiga murojaat qiladi, uzun URL'ni oladi, uni kelajakdagi so'rovlar uchun Redisga saqlaydi va keyin foydalanuvchiga qaytaradi.

Bu yondashuv ma'lumotlar bazasiga tushadigan yuklamani 90-95% gacha kamaytiradi.

Yechim №2: Ma'lumotlar bazasini kengaytirish (Database Sharding)
Agar bitta ma'lumotlar bazasi milliardlab yozuvlarni saqlashga qiynalsa, biz ma'lumotlarni bir nechta bazalarga bo'lib tashlaymiz. Bu jarayon Sharding deyiladi.

Mantiq: short_code ning birinchi belgisiga qarab ma'lumotlarni bo'lishimiz mumkin. Masalan, 'a' dan 'm' gacha boshlanadigan barcha kodlar 1-bazaga, 'n' dan 'Z' gacha bo'lganlar esa 2-bazaga yoziladi. Bu ham yozish, ham o'qish yuklamasini taqsimlaydi.

Ko'rib turganingzdek, oddiy tuyulgan masalaga ham o'zgacha yondashish, iloji boricha ko'proq nimaga va qanday degan savollar berib chiqish muhim hisoblanadi. Hozir men bu muammoga yechimni iloji boricha qisqa va tushunarliroq shaklda yozishga harakat qildim, lekin buniyam turli xil yechimlar va yo'llar bilan yanayam samaraliroq va yaxshiroq qilish imkoniyatlari bor.

Hozircha faqat matn ko'rinishida yozishga sharoit bo'lyapti, lekin keyinroq shu mavzularni youtubega video shaklda joylashni boshlayman va shunda tushunishga osonroq va oddiyroq bo'ladi deb o'ylayman

@mabrur_dev

ias)*&U£$*(QYU894erujalksfj012

Ko'p loyihalarda, ayniqsa jamoa kattalashganda, Gitni boshqarish haqiqiy bosh og'rig'iga aylanadi. Kimdir main'ga to'g'ridan-to'g'ri commit qiladi, boshqasi hali pishmagan feature'ni merge qilib yuboradi va production'dagi kod "sinadi".

Bunday holatlarga tushmaslik uchun ancha tartibli va sinovdan o'tgan Gitflow workflowidan foydalansa bo'ladi. Bu flowni yana bir yaxshi tomoni muntazam versiyalarga (versioned releases) ega bo'lgan loyihalar uchun ham ideal yechim.

Hozir bu workflow ishlashini sodda tilda tushunishga harakat qilamiz.

Menda ikkita doimiy (long-lived) branch bor:

🌳 Master/Main branch:
Bu - production'dagi, ya'ni real foydalanuvchilar ishlatayotgan eng barqaror va toza kod. Bu yerga to'g'ridan-to'g'ri hech narsa commit qilinmaydi! Main'dagi har bir commit - bu yangi versiya (release) degani va u v1.0.1, v1.1.0 kabi tag'lar bilan belgilanadi.

🌿 Develop branch:
Bu - bizning asosiy ish maydonimiz. Barcha yangi feature'lar shu yerga yig'iladi. Develop branch'i kelajakdagi release uchun tayyorlanayotgan kodning eng so'nggi holatini saqlab yuradi.

Endi esa, asosiy ishni bajaradigan vaqtinchalik (short-lived) branch'lar:

💡 Feature branch (feature/*)
Har bir yangi feature (funksionallik) uchun men develop'dan alohida feature/task-111-user-authentication kabi yangi branch ochaman. Bu ishni boshqa feature'lardan to'liq izolyatsiya qiladi. Feature tayyor bo'lib, code review'dan o'tgach, u develop'ga merge qilinadi va o'chiriladi.

📦 Release branch (release/*)
develop'da keyingi versiya uchun kerakli feature'lar yig'ilgach, men release/v1.1.0 kabi yangi release branch'ini yarataman. Bu branch'da faqat release'ga tayyorgarlik ishlari qilinadi: oxirgi bug'lar tuzatiladi, dokumentatsiya yangilanadi, versiya raqami o'zgartiriladi. Yangi feature qo'shilmaydi.
Release tayyor bo'lgach, u bir vaqtning o'zida:
- main'ga merge qilinadi va tag bilan belgilanadi (bu endi production'dagi kod).
- develop'ga ham merge qilinadi (chunki release branch'da qilingan o'zgarishlar develop'da ham bo'lishi kerak).
Keyin bu release branch ham o'chiriladi.

🔥 Hotfix branch (hotfix/*)
Tasavvur qiling, production'da shoshilinch bug chiqib qoldi va uni darhol tuzatish kerak. Bunday paytda men develop'ga tegmasdan, to'g'ridan-to'g'ri main'dan hotfix/task-212-login-bug kabi branch ochaman. Bug tuzatilgach, bu hotfix branch xuddi release kabi ham main'ga, ham develop'ga merge qilinadi. Bu develop'da eski bug'ning qayta paydo bo'lishining oldini oladi.

Xulosa qilib aytganda, bu workflow kodni toza saqlashga, jamoaviy ishni tartibga solishga va release'larni oson boshqarishga yordam beradi. Loyihangiz biroz murakkablashishi bilan uning afzalliklarini seza boshlaysiz.

Siz o'z loyihalaringizda qanday Git branching strategy'sidan foydalanasiz? Izohlarda tajribangiz bilan bo'lishing! 👇

@mabrur_dev

Eshitdilarmi, Apple yashirincha IOS'ni fundamental qismlarini qayta yozib chiqyaptimish. Bu Swift yoki Objective-C damas, umuman boshqa tilda - Rustda bo'larkan!

Iphoneni quyi qismlari - xotira boshqaruvi, concurrency, applar crash bo'lgandagi holatlar Rust g'oyalari bilan qayta qurib chiqilayotgan ekan.

Bu haqida hali to'liq ko'rib chiqmadim, bilganlar bo'lsa kommentariyada yozib ko'proq ma'lumot berselar bo'ladi

Osonakanu ishilar )

Rate Limiting - Backenddagi Qalqon🛡️

Siz o'z tizimingizga qancha resurs ajratmang, uning baribir o'z chegarasi bor. Ba'zida trafik kutilmaganda keskin oshadi (bursts), userlar agressiv retry qiladi yoki bitta servisdagi muammo butun tizimni ishdan chiqaradi. Aynan shunday paytlarda Rate Limiting (so'rovlarni cheklash) ancha as qotadi.

Oddiy qilib aytganda, Rate Limiter - bu API oldida turgan "qo'riqchi" (bouncer). U tizimga kirayotgan so'rovlar oqimini nazorat qilib turadi, serverlarni haddan tashqari yuklanishiga, brute-force hujumlariga va boshqa shunga o'xshash holatlarga yo'l qo'ymaydi. Agar klient belgilangan me'yordan oshsa, Rate Limiter unga ko'pchilik ko'rgan 429 Too Many Requests xatoligini qaytaradi.

Hozir eng keng tarqalgan Rate Limiting algoritmlarini ko'rib chiqamiz:

1. Fixed Window Counter
Bu eng oddiy usul. Vaqt qat'iy oraliqlarga ("windows") bo'linadi (masalan, har daqiqada). Har bir oyna uchun so'rovlar hisoblagichi (counter) bo'ladi.

Qanday ishlaydi: Agar daqiqasiga 100 ta so'rov limiti bo'lsa, 14:00 da hisoblagich 0 ga tushadi va 14:01 gacha kelgan so'rovlarni sanaydi. 101-so'rov rad etiladi. 14:01 da hisoblagich yana 0 ga tushadi.

Asosiy muammo: Oyna chegarasidagi yuklama. Masalan, klient 14:00:59 da 100 ta va 14:01:01 da yana 100 ta so'rov yuborishi mumkin. Natijada tizim 2 soniya ichida 200 ta so'rov qabul qiladi, bu esa limitimizda yanayam qo'shimcha limitlar keltiradi.

2. Sliding Window Log
Bu usul yuqoridagi muammoni hal qiladi. U har bir so'rovning timestamp'ini (vaqt belgisini) saqlaydi.

Qanday ishlaydi: Yangi so'rov kelganda, algoritm joriy vaqtdan bir oyna (masalan, 1 daqiqa) orqadagi barcha timestamp'larni o'chiradi. Qolgan timestamp'lar soni limitdan oshmasa, so'rov qabul qilinadi va uning timestamp'i jurnalga qo'shiladi.

Afzalligi: Juda aniq ishlaydi, chegara muammosi yo'q.

Kamchiligi: Har bir foydalanuvchining har bir so'rovi uchun timestamp saqlash katta trafikda juda ko'p xotira talab qilishi mumkin.

3. Sliding Window Counter
Bu - avvalgi ikki usulning yaxshi tomonlarini birlashtirgan gibrid yondashuv, "oltin o'rtalik".

Qanday ishlaydi: Bu usul timestamp'lar jurnalini saqlamaydi. Buning o'rniga, u oldingi va joriy oynalardagi hisoblagichlardan foydalanib, sliding windowdagi so'rovlar sonini taxminan hisoblaydi. Bu orqali resurs sarfiyam, aniqligam yaxshi muvozanatlanadi.

Afzalligi: Xotirani tejamkorligi va yetarlicha aniqlik. Ko'pgina yirik tizimlar aynan shu yondashuvdan foydalanadi.

4. Token Bucket
Bu eng mashhur va moslashuvchan strategiyalardan biri.

Tasavvur qiling, bir chelak (bucket) bor va unga doimiy tezlikda "token"lar solib turiladi. Har bir kiruvchi so'rov o'tish uchun chelakdan bitta token olishi kerak. Agar chelakda token bo'lmasa, so'rov rad etiladi yoki navbatga qo'yiladi.

Eng muhim xususiyati: Qisqa muddatli keskin yuklamalarga (bursts) ruxsat beradi. Agar chelak tokenlarga to'la bo'lsa, klient bir vaqtning o'zida chelak sig'imicha so'rov yuborishi mumkin. Bu tizimga moslashuvchanlik beradi.

5. Leaky Bucket
Bu strategiya Token Bucket'ga o'xshaydi, lekin boshqacha maqsadda xizmat qiladi.

Qanday ishlaydi: Kiruvchi so'rovlar qanchalik tez kelishidan qat'iy nazar, chelakka (bu yerda u FIFO - first in first out navbati) tushadi. Chelak esa o'z "tubidan" doimiy bir xil tezlikda so'rovlarni "oqizib" chiqaradi va tizimga uzatadi. Agar chelak (navbat) to'lib qolsa, yangi so'rovlar rad etiladi.

Eng muhim xususiyati: Chiquvchi oqimni doimiy bir tekis tezlikda ushlab turadi. U burst'larni "siyqallaydi" va tizimga so'rovlarni barqaror oqimda yetkazib beradi.

Xulosa qilib aytadigan bo'lsak, eng yaxshi algoritm yo'q. Tanlov sizning talablaringizga bog'liq: agar tizimingiz qisqa muddatli burst'larni qabul qila olsa, Token Bucket yaxshi tanlov. Agar sizga tizimga tushadigan yuklamani doimiy va bir tekisda ushlab turish muhim bo'lsa, Leaky Bucket yoki Sliding Window strategiyalari ko'proq mos keladi.

@mabrur_dev

Intervyuda ko'p uchraydigan savollardan biri: Cookies vs Sessions, Asosiy farqlari nimada?

Javoblarni kutaman.

Sonnet 4.5 chiqdi. Kutilmalar katta, ko'ramiz qanchalik kuchaydi, token usage qanchalik optimize qilingan, yoki yanayam qimmatlashdimi

Prompt engineering, prompt yozdirish va promptni debug qilish bo'yicha gemini 2.5 pro ga teng keladigan model yo'q. Codingda Claudega. Umumiy kundalik ishlarda esa GPTga.

Har kuni 3-4 xil model ishlatib yuradigan inson sifatida, tajribamdan kelib chiqib aytayotgan fikrlarim, noto'g'ri aytayotgan bo'lsam to'g'irlang )

Efirda reklama, lekin bu safargisi foydali )

Kimdir shaxsiy proyektini "tuzukroq" joyga, ortiqcha bosh og'riqsiz deploy qilmoqchi bo'lsa, sizga juda zo'r maslahatim bor.

O'zim doim ishlatib yurgan servisni sizgayam ilindim.

O'zimiziklarga maxsus "jigarlik" havolasi:
👉 https://railway.com?referralCode=NajBle

Shu referal havoladan o'tib ro'yxatdan o'tsangiz, sizga $20 depozit sovg'a qilinadi. Menam quruq qolmayman (akkountimga 15% daromad)

Ana xolos😕