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
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
👍7❤4🔥4👨💻1
Intervyuda ko'p uchraydigan savollardan biri: Cookies vs Sessions, Asosiy farqlari nimada?
Javoblarni kutaman.
Javoblarni kutaman.
👍8
Sonnet 4.5 chiqdi. Kutilmalar katta, ko'ramiz qanchalik kuchaydi, token usage qanchalik optimize qilingan, yoki yanayam qimmatlashdimi
❤7
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 )
Har kuni 3-4 xil model ishlatib yuradigan inson sifatida, tajribamdan kelib chiqib aytayotgan fikrlarim, noto'g'ri aytayotgan bo'lsam to'g'irlang )
🔥24👍7
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)
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)
Railway
Railway is an infrastructure platform where you can provision infrastructure, develop with that infrastructure locally, and then deploy to the cloud.
🔥9❤1
Bularni ko'rib, nima deyishniyam bilmaysan😅
OpenAI keylari tursin, Databaseini parollarigacha push qivorgan. Menimcha bularning katta qismi oxirgi paytdagi dasturlashdan xabari yo'q vibecoderlar bo'lsa kerak
OpenAI keylari tursin, Databaseini parollarigacha push qivorgan. Menimcha bularning katta qismi oxirgi paytdagi dasturlashdan xabari yo'q vibecoderlar bo'lsa kerak
1😁36❤3🔥2
Atmos payment integration bilan ishlab ko'rganlar bormi? Dokumentatsiyasini o'qigandim paymentlar uchun yaxshi solutionlari bor ekan. Stabillik, support va foizlari qanaqa, xabarilar bormi, maslahat berasilarmi?
❤4
💥 Hayotimdagi eng qimmatga tushgan 𝐧𝐩𝐦 𝐬𝐭𝐚𝐫𝐭.
Taxminan bir oy oldin LinkedIn'dan bir HR yozib qoldi. Profiliga qaraganda hamma narsa joyida edi: rasmi bor, o‘zi haqida aniq yozgan, 500 ga yaqin "connection"lari bor, hatto orasida men shaxsan taniydigan odamlar ham bor ekan.
U Web3 bo‘yicha ish taklif qildi: to‘liq masofaviy, talablari uncha ko‘p emas, "stack"imga ham rosa mos tushardi. Xuddi osmondan tushgandek, orzuyingdagidek takliflardan biri edi-da.
CV'mni jo‘natdim. Deyarli darhol javob keldi: “Zo‘r! Test topshirig‘ini hoziroq boshlayvering.”
Biroz g‘alati tuyuldi: na intervyu bor, na suhbat. Shunchaki "testni qiling". Lekin topshiriq oddiy edi: kichkina proyektni bir ko‘rib chiqish. Xullas, reponi "clone" qildim, o‘zimda ishga tushirdim... va ortiqcha o‘ylab ham o‘tirmadim.
⏳ Bir necha soatdan keyin kripto hamyonimni ochsam... dong qotib qoldim. Balansda deyarli pul qolmagandi.
Hech qanaqa fishing ssilka bosmadim. Soxta saytlarga kirmadim. Shubxali "approve" (tasdiqlash) bermadim. Shunchaki... hammasi yo‘q bo‘lib qoldi.
Tun bo‘yi kodni titkilab chiqib, axiyri sababini topdim. Gap shundaki, proyekt ichida zararli "dependency" (bog‘liqlik) bor ekan. U ishga tushishi bilan yashirin skript ham avtomatik ishlab ketgan. U "environment variables", hamyon ma’lumotlari, sessiya tokenlarini bildirmasdan yig‘ib, begona serverga jo‘natib yuborgan.
O‘sha soniya menga $25,000 ga tushdi va ishlash uslubimni butunlay o‘zgartirib yubordi.
🧠 O‘shandan beri: • Notanish proyektlarni faqat Docker yoki virtual mashinada (VM) ishga tushiradigan bo‘ldim. • npm install qilishdan oldin har bir "dependency"ni obdon tekshiraman. • Asosiy pulimning hammasi Ledger'da (sovuq hamyonda) turadi.
Chunki dasturchi xavfsizligi bu shunchaki kuchli parol yoki VPN ishlatish degani emas. Ba’zan hammasi bitta kichkina qarorga — npm start tugmasini bosish yoki bosmaslikka bog‘liq bo‘lib qolar ekan.
💬 $25 ming yo‘qotish alamli. Lekin har doim ishimning oddiy bir qismi deb hisoblagan narsamga bo‘lgan ishonchni yo‘qotish undan ham og‘irroq ekan.
Agar siz ham Web3 sohasida ishlasangiz yoki hamyonlar bilan integratsiya qilsangiz, iltimos, mening xatoimni takrorlamang.
(c) Daria Kazantceva
@mabrur_dev
Taxminan bir oy oldin LinkedIn'dan bir HR yozib qoldi. Profiliga qaraganda hamma narsa joyida edi: rasmi bor, o‘zi haqida aniq yozgan, 500 ga yaqin "connection"lari bor, hatto orasida men shaxsan taniydigan odamlar ham bor ekan.
U Web3 bo‘yicha ish taklif qildi: to‘liq masofaviy, talablari uncha ko‘p emas, "stack"imga ham rosa mos tushardi. Xuddi osmondan tushgandek, orzuyingdagidek takliflardan biri edi-da.
CV'mni jo‘natdim. Deyarli darhol javob keldi: “Zo‘r! Test topshirig‘ini hoziroq boshlayvering.”
Biroz g‘alati tuyuldi: na intervyu bor, na suhbat. Shunchaki "testni qiling". Lekin topshiriq oddiy edi: kichkina proyektni bir ko‘rib chiqish. Xullas, reponi "clone" qildim, o‘zimda ishga tushirdim... va ortiqcha o‘ylab ham o‘tirmadim.
⏳ Bir necha soatdan keyin kripto hamyonimni ochsam... dong qotib qoldim. Balansda deyarli pul qolmagandi.
Hech qanaqa fishing ssilka bosmadim. Soxta saytlarga kirmadim. Shubxali "approve" (tasdiqlash) bermadim. Shunchaki... hammasi yo‘q bo‘lib qoldi.
Tun bo‘yi kodni titkilab chiqib, axiyri sababini topdim. Gap shundaki, proyekt ichida zararli "dependency" (bog‘liqlik) bor ekan. U ishga tushishi bilan yashirin skript ham avtomatik ishlab ketgan. U "environment variables", hamyon ma’lumotlari, sessiya tokenlarini bildirmasdan yig‘ib, begona serverga jo‘natib yuborgan.
O‘sha soniya menga $25,000 ga tushdi va ishlash uslubimni butunlay o‘zgartirib yubordi.
🧠 O‘shandan beri: • Notanish proyektlarni faqat Docker yoki virtual mashinada (VM) ishga tushiradigan bo‘ldim. • npm install qilishdan oldin har bir "dependency"ni obdon tekshiraman. • Asosiy pulimning hammasi Ledger'da (sovuq hamyonda) turadi.
Chunki dasturchi xavfsizligi bu shunchaki kuchli parol yoki VPN ishlatish degani emas. Ba’zan hammasi bitta kichkina qarorga — npm start tugmasini bosish yoki bosmaslikka bog‘liq bo‘lib qolar ekan.
💬 $25 ming yo‘qotish alamli. Lekin har doim ishimning oddiy bir qismi deb hisoblagan narsamga bo‘lgan ishonchni yo‘qotish undan ham og‘irroq ekan.
Agar siz ham Web3 sohasida ishlasangiz yoki hamyonlar bilan integratsiya qilsangiz, iltimos, mening xatoimni takrorlamang.
(c) Daria Kazantceva
@mabrur_dev
👍31❤7🔥2
Hozirgi startaplarda nima muhim? Tezlik.
Frontendda Vite bilan proyektni "uchirib" yig'ib tashlayapsiz. Chiroyli qilib TypeScript interface'laringizni yozgansiz, hamma narsa joyida.
Endi... backend...
Ko'pincha sekinlashish shu joydan boshlanadi. Frontenddagi type'laringizni endi Node.js, Python yoki Goga "tarjima" qilib chiqishingiz kerak. Ular bir-biriga mos kelishi shart.
Keyin DB schemasi haqida alohida bosh qotirasiz. Migration yozasiz.
Eng "og'riqli" joyi - tasavvur qiling, userga yangi bitta field qo'shish kerak. Nima qilasiz?
- DB migration yozasiz.
- Backenddagi DTO yoki Serializerni o'zgartirasiz.
- API endpointni logikasini to'g'irlaysiz.
- Va nihoyat frontenddagi interfaceni yangilaysiz.
Bitta maydon uchun shuncha ovoragarchilik. Ayniqsa, komandada backenddan unchalik xabari yo'q dasturchilar bo'lsa, bu narsa startapni juda sekinlashtiradi.
convex.dev aynan shu muammoni hal qilishga harakat qilyapti.
G'oya juda oddiy: "Nega hammasini bitta tilda, bitta joyda qilmaymiz?"
Baza sxemasiniyam, API funksiyalaringizniyam, auth logikangizniyam - hammasini pure TypeScript'da yozasiz. Kodingiz frontendni yonida turadi.
Eng zo'r tomoni: Bitta joyda schemani o'zgartirsangiz, butun proyekt bo'ylab autocomplete va type-checking ishlaydi. "Backenddagi type frontendga to'g'ri kelmay qoldi" degan muammo bo'lmaydi. AI yordamida generate qilsangiz bo'ladi. Har-xil cron joblar, real-time yoki file storagelariyam bor.
Bunga alternativ trigger.dev niyam ishlatib ko'rsangiz bo'ladi.
Shunaqa, do'stlar,dangasalashib tezlashib ketyapmiz
@mabrur_dev
Frontendda Vite bilan proyektni "uchirib" yig'ib tashlayapsiz. Chiroyli qilib TypeScript interface'laringizni yozgansiz, hamma narsa joyida.
Endi... backend...
Ko'pincha sekinlashish shu joydan boshlanadi. Frontenddagi type'laringizni endi Node.js, Python yoki Goga "tarjima" qilib chiqishingiz kerak. Ular bir-biriga mos kelishi shart.
Keyin DB schemasi haqida alohida bosh qotirasiz. Migration yozasiz.
Eng "og'riqli" joyi - tasavvur qiling, userga yangi bitta field qo'shish kerak. Nima qilasiz?
- DB migration yozasiz.
- Backenddagi DTO yoki Serializerni o'zgartirasiz.
- API endpointni logikasini to'g'irlaysiz.
- Va nihoyat frontenddagi interfaceni yangilaysiz.
Bitta maydon uchun shuncha ovoragarchilik. Ayniqsa, komandada backenddan unchalik xabari yo'q dasturchilar bo'lsa, bu narsa startapni juda sekinlashtiradi.
convex.dev aynan shu muammoni hal qilishga harakat qilyapti.
G'oya juda oddiy: "Nega hammasini bitta tilda, bitta joyda qilmaymiz?"
Baza sxemasiniyam, API funksiyalaringizniyam, auth logikangizniyam - hammasini pure TypeScript'da yozasiz. Kodingiz frontendni yonida turadi.
Eng zo'r tomoni: Bitta joyda schemani o'zgartirsangiz, butun proyekt bo'ylab autocomplete va type-checking ishlaydi. "Backenddagi type frontendga to'g'ri kelmay qoldi" degan muammo bo'lmaydi. AI yordamida generate qilsangiz bo'ladi. Har-xil cron joblar, real-time yoki file storagelariyam bor.
Bunga alternativ trigger.dev niyam ishlatib ko'rsangiz bo'ladi.
Shunaqa, do'stlar,
@mabrur_dev
🔥20
Sun'iy Intellekt o'smirlarni aqlliroq qilyapti... lekin bu aql ancha "yuzakiroq"😐
Oxford University Press'ning yangi tadqiqoti qiziq holatni ko'rsatdi: Britaniyadagi 10 ta maktab o'quvchisidan 8 tasi dars qilishda allaqachon AI'dan foydalanar ekan.
Ular masalalarni tezroq yechyapti, referatlarni bir zumda tayyorlayapti va "mashinalar bilan birga fikrlayapti". Bu xuddi "superkuch"ga o'xshaydi.
Lekin bitta "lekin"i bor: ChatGPT'ga kirishni o'chirsangiz, bu "superkuch" ham o'chib qoladi.
60% o'quvchi AI ularning ko'nikmalariga zarar yetkazayotganini tan olgan.
25% uchun o'qish "haddan tashqari oson" bo'lib qolgan.
Har o'ninchisi esa deyarli critical thinkingni to'xtatganini aytgan.
Oxford University Press'ning yangi tadqiqoti qiziq holatni ko'rsatdi: Britaniyadagi 10 ta maktab o'quvchisidan 8 tasi dars qilishda allaqachon AI'dan foydalanar ekan.
Ular masalalarni tezroq yechyapti, referatlarni bir zumda tayyorlayapti va "mashinalar bilan birga fikrlayapti". Bu xuddi "superkuch"ga o'xshaydi.
Lekin bitta "lekin"i bor: ChatGPT'ga kirishni o'chirsangiz, bu "superkuch" ham o'chib qoladi.
60% o'quvchi AI ularning ko'nikmalariga zarar yetkazayotganini tan olgan.
25% uchun o'qish "haddan tashqari oson" bo'lib qolgan.
Har o'ninchisi esa deyarli critical thinkingni to'xtatganini aytgan.
👍8
Mabrur - IT Blog 🇵🇸
Sun'iy Intellekt o'smirlarni aqlliroq qilyapti... lekin bu aql ancha "yuzakiroq"😐 Oxford University Press'ning yangi tadqiqoti qiziq holatni ko'rsatdi: Britaniyadagi 10 ta maktab o'quvchisidan 8 tasi dars qilishda allaqachon AI'dan foydalanar ekan. Ular…
Bu holatni qanday o'zgartirish mumkin? Ta'lim endi qanday bo'lishi kerak?
Mening gipotezam: Muammo AI'da emas. Muammo biz unga berayotgan vazifalarda.
Dasturchi Stack Overflow'dan shunchaki kodni copy-paste qilsa, u hech qachon o'rganmaydi. Bu ham xuddi shu holat. AI - bu shunchaki juda kuchli "kalkulyator". Biz kalkulyatorlarni ta'qiqlamadik, biz ulardan foydalanishni o'rgatdik.
Ta'lim tizimini o'zgartirish uchun nima qilish kerak deb o'ylayman:
Vazifalarni o'zgartirish kerak. "Referat yozib kel" degan vazifaning o'zi eskirgan. Odamlar baribir buni AI bilan qiladi. Endi vazifa boshqacha bo'lishi kerak: "AI yordamida referat yoz, lekin undagi 3 ta xatoni topib, faktlar bilan isbotlab ber" yoki "AI taklif qilgan 2 ta yechimdan qaysi biri optimal ekanligini tushuntir".
O'quvchi mavzu bo'yicha AI bilan to'liq tayyorlanib keladi, lekin baholash referat yoki yozma ish uchun emas, o'quvchi o'z faktlarini va javoblarini qanchalik oqlay oladi va og'zaki himoyalay oladi, shunga qarab berilishi kerak.
AI'ni "savol-javob" uchun emas, "simulyator" sifatida ishlatish. AI'dan "javob nima?" deb so'rashni to'xtatib, undan "aqlli sparring-hamkor" sifatida foydalanish kerak. O'quvchi AI'ga o'z yechimini aytib, AI'dan uni tanqid qilishni yoki"zaif tomonlarini ko'rsatishni so'rashi kerak.
Fokus generatsiyadan validatsiyaga o'tishi kerak. Ma'lumotni yaratish endi qimmat emas. Ma'lumotni tekshirish va tasdiqlash eng qimmat ko'nikmaga aylanadi. Biz o'quvchilarga bo'sh varaqdan yozishni emas, tayyor ma'lumotning qanchalik to'g'ri ekanligini aniqlashni o'rgatishimiz kerak.
Xullas, ta'lim tizimi AI'ga qarshi kurashishdan ko'ra, AI bilan samarali ishlashni o'rgatishi kerak. Menimcha ta'lim endi informatsiya emas, ko'proq interpretatsiyaga bog'lanadigan davrdamiz.
Siz nima deysiz, kelajakda "tanqidiy fikrlash"ni qanday saqlab qolamiz, fikrlar bormi?
@mabrur_dev
Mening gipotezam: Muammo AI'da emas. Muammo biz unga berayotgan vazifalarda.
Dasturchi Stack Overflow'dan shunchaki kodni copy-paste qilsa, u hech qachon o'rganmaydi. Bu ham xuddi shu holat. AI - bu shunchaki juda kuchli "kalkulyator". Biz kalkulyatorlarni ta'qiqlamadik, biz ulardan foydalanishni o'rgatdik.
Ta'lim tizimini o'zgartirish uchun nima qilish kerak deb o'ylayman:
Vazifalarni o'zgartirish kerak. "Referat yozib kel" degan vazifaning o'zi eskirgan. Odamlar baribir buni AI bilan qiladi. Endi vazifa boshqacha bo'lishi kerak: "AI yordamida referat yoz, lekin undagi 3 ta xatoni topib, faktlar bilan isbotlab ber" yoki "AI taklif qilgan 2 ta yechimdan qaysi biri optimal ekanligini tushuntir".
O'quvchi mavzu bo'yicha AI bilan to'liq tayyorlanib keladi, lekin baholash referat yoki yozma ish uchun emas, o'quvchi o'z faktlarini va javoblarini qanchalik oqlay oladi va og'zaki himoyalay oladi, shunga qarab berilishi kerak.
AI'ni "savol-javob" uchun emas, "simulyator" sifatida ishlatish. AI'dan "javob nima?" deb so'rashni to'xtatib, undan "aqlli sparring-hamkor" sifatida foydalanish kerak. O'quvchi AI'ga o'z yechimini aytib, AI'dan uni tanqid qilishni yoki"zaif tomonlarini ko'rsatishni so'rashi kerak.
Fokus generatsiyadan validatsiyaga o'tishi kerak. Ma'lumotni yaratish endi qimmat emas. Ma'lumotni tekshirish va tasdiqlash eng qimmat ko'nikmaga aylanadi. Biz o'quvchilarga bo'sh varaqdan yozishni emas, tayyor ma'lumotning qanchalik to'g'ri ekanligini aniqlashni o'rgatishimiz kerak.
Xullas, ta'lim tizimi AI'ga qarshi kurashishdan ko'ra, AI bilan samarali ishlashni o'rgatishi kerak. Menimcha ta'lim endi informatsiya emas, ko'proq interpretatsiyaga bog'lanadigan davrdamiz.
Siz nima deysiz, kelajakda "tanqidiy fikrlash"ni qanday saqlab qolamiz, fikrlar bormi?
@mabrur_dev
👍19🔥1
AWS US regionlarida down bop qoldi )
Dockerdayam shu ahvol.
Shu sabab ko'p sitelar o'tirib qolyapti
@mabrur_dev
Dockerdayam shu ahvol.
Shu sabab ko'p sitelar o'tirib qolyapti
@mabrur_dev
👨💻12❤2😁1
Hullas, anchadan beri podyezdimizga kelib qogan, qoshnilar korm bilan boqib yurishibdi. Bizi uyga kirmoqchi bo’lib eshigimizni tagida yotibti, olib kirib ketolmaymiz🥲
Yaxshi boqa oladiganlar, olib ketmoqchi bo’lganlar yozinglar. Zotdor, uy mushugili ko’rinib turipti. Jinsi Mujik. Tozalab, yuvintirib bervoramiz )
Yaxshi boqa oladiganlar, olib ketmoqchi bo’lganlar yozinglar. Zotdor, uy mushugili ko’rinib turipti. Jinsi Mujik. Tozalab, yuvintirib bervoramiz )
👍5😁2