IT with Bobur👨‍💻

GC yani Garbage Collector. Bu deyarli barcha tillar mavjud bo'lib uning vazifasi dastur ishlayotgan bir paytda keraksiz bo'lib qolgan xotirani avtomatik tozalash mexanizimidir. Umumiy g'oya bitta objectga hechkim murojat qilmayabdimi demak uni kill qil.…

GC yani Garbage Collector. Bu deyarli barcha tillar mavjud bo'lib uning vazifasi dastur ishlayotgan bir paytda keraksiz bo'lib qolgan xotirani avtomatik tozalash mexanizimidir. Umumiy g'oya bitta objectga hechkim murojat qilmayabdimi demak uni kill qil. Lekin xar xil tillarda turlicha ishlatilinadi. Masalan: Pythonda objectda reference count bo'ladi. Siz u objectni qayerdadur o'zgaruvchiga tenglasayiz count bittaga oshadi o'zgaruvchidan uzsang esa bittaga kamayadi va oxiri 0 bo'lganda object xotiradan o'chiriladi. Javada esa bir oz boshqacha. GC vaqti vaqti bilan heapni tekshirib turadi. Agar objectga hech qanday yo'l bilan yetib bo'lmasa (unreachable object) GC uni keyingi yig'ishda o'chiradi. Yana bir muxim nuqta Javada GC algoritmlari murakkab: G1 GC, ZGC, Shenandoah, Parallel GC. Lekin hammasining maqsadi bir xil ishlatilmayotgan objectlarni topish. Dart esa javaga o'xshash. Agar objectda reference qolmasa GC uni o'chirib tashlaydi. Dart VM asosan Generational Garbage Collection ishlatadi. Young generation yani yangi yaratilingan object. Old generation esa eski yaratilingan object. Ko'p objectlar tezda yo'q bo'lib ketgani uchun GC avval young generationni tez tez tozalaydi. Bu Flutter ilovalarini tez ishlashiga yordam beradi. 🚀 @ITwithBobur

Nega claude unaqa a. bitta ishni doim ikkita qiladi. buni kodini yaxshilar review qimagan odamni boshiga balo bo'ladi AI birkun.

Nega claude unaqa a. bitta ishni doim ikkita qiladi. buni kodini yaxshilar review qimagan odamni boshiga balo bo'ladi AI birkun.

AI o'ldiryapti. Plan bo'lsa bajarildi, tasklar tugadi, Claude limit bo'lsa hali bor, lekin baxt yo'q. Xullas, atrofimdagi ko'p aytishniklar dasturlashdan zerikib qoldi. Shunchaki prompt yozadi, Claude ishni qilib beradi. Oldingidek ishidan mazza qilish yo'q. Menimcha, bunga sabab oddiy: ular oldin kod yozib, uni ishlashidan oladigan dopamin endi yo'q. Qiyin, murakkab va soatlab, ba'zan esa kunlab vaqt oladigan tasklarni AI soniyalar ichida qilib beryapti, bu esa vaqt tejashga yordam beradi, lekin dopaminni olib ham qo'yadi. Nima yechim qilsak bo'ladi? Aytaylik, sizga berilgan tasklarni takror-takror qiladigan qismingizni AI qilsin, yangicha feature — oldin siz ishlamagan, biroz murakkab qismini esa siz qiling, shu bilan balansni ushlash mumkin. Mendayam bo'lgan bu codingdan zerikish, lekin men yechim qilgan ish bunday: men arxitekturani qo'lda yozib chiqaman, qolganini AIga topshiraman, ya'ni "sen BaseCubitdan instance olib, menga NotificationPageListCubit yoz, BlaBlaModelga qarab menga NotificationListModel yoz". Yana bir ish — mobilda ko'p kod yozmayapman hozir, ko'proq backendda qo'lda kod yozyapman, bu ham balans ushlashga yordam beryapti. Masalan, kunduzi 8 soat ishimda 4-5 soatda tasklarni tugataman-da, backendga o'tib API'larni o'zgartirib o'tiraman. Menimcha, muammo AI'da emas. Muammo shundaki, ba'zan biz ishning eng qiziq qismini ham AI'ga topshirib qo'yamiz.

Bu yerda Samandar akani bugun chiqqan youtube videosini reposti bo'lishi mumkin edi lekin ushbu videoda aka hechkimga aytmang deyishganligi uchun aytmadim.

AI va Dasturlash: 2026 Bugungi kunda AI ishlatish odatiy holga aylanib bormoqda. Bu shunchaki trend emas — bu butun soha va mavzular o'zgarayotganining belgisi. Oldin developerlar ko'proq texnologiya bo'yicha ajralardi: frontend, backend, mobile. Hozir esa bu chegaralar asta-sekin yo'qolib boryapti. Sababi oddiy — AI ko'p "texnik" ishlarni avtomatlashtirib qo'ydi. Bu nimadan signal? Bu shuni anglatadiki, endi faqat framework yoki til bilish yetarli emas. Kod yozishning o'zi endi asosiy skill emas. AI bilan CRUD yozish ancha osonlashdi, oddiy API yoki UI qilish tezlashdi va ilgari ko'p vaqt oladigan boilerplate kodlar deyarli ahamiyatsiz bo'lib qoldi. Demak, value boshqa joyga ko'chmoqda. Nimaga tayyor turish kerak? Bugungi kunda AI bilan raqobatlashish emas, balki u bilan hamkorlik qilish muhim. Texnologiyalar juda tez o'zgarayotgan bir paytda, ularga moslashish va yangiliklarni tez o'zlashtira olish katta ustunlik beradi. Endi faqat kod yozuvchi bo'lish yetarli emas — muammoni tushunib, uni samarali yecha oladigan "problem solver" bo'lish zarur. Shu bilan birga, doimiy o'rganish va o'z ustida ishlash bu davrda eng muhim odatlardan biriga aylanmoqda. Endi nimani o'rganish kerak? Hozirgi davrda asosiy e'tibor Software Engineering asoslariga qaratilishi kerak — ya'ni architecture va system design kabi tushunchalarni chuqur anglash muhim. AI yordam berishi mumkin, lekin u xato ham qiladi, shuning uchun debugging va mustaqil fikrlash ko'nikmalari juda zarur. Bundan tashqari, xavfsizlik asoslarini bilish ham muhim, chunki AI yozgan kod har doim ham xavfsiz bo'lavermaydi. Jamoa bilan samarali ishlash uchun communication skill'lar ham katta rol o'ynaydi. Va eng muhimi — faqat kod yozish emas, balki nima uchun yozayotganingni tushunish, ya'ni product thinking rivojlantirish kerak. Yangi davr: Endi gap "men Flutterchiman" yoki "men backendchiman"da emas. Gap — "men muammoni yecha olaman"da. AI kuchli — lekin u hali ham tool. Uni to'g'ri ishlata olganlar yutadi. Don't just learn tools. Learn how to think. 🚀 @ITwithBobur

Siz ishlatadigan SVG ilovangizni og'ir ishlashiga sabab bo'ladi. Buni bilarmidinggiz? Keling birinchi farqlarni ko'rib chiqamiz. JPG nima? - bu siqilgan rasm formati. Fotosuratlar, manzaralar, odamlar rasmi — bular uchun ideal. Hajmi kichik, lekin sifati biroz yo'qoladi (siqish tufayli). Telefon bu rasmni shunchaki ekranga "yopishtirib" qo'yadi — GPU bu ishni bir zumda bajaradi. PNG nima? - bu ham tayyor piksellik rasm, lekin sifat yo'qolmaydi va shaffof fon qo'llab-quvvatlanadi. Ikonkalar, logotiplar, shaffof elementlar uchun ishlatiladi. JPG kabi — telefon uni xotiradan olib, ekranga tez chizadi. SVG nima? - bu esa boshqacha. Bu tayyor rasm emas — bu "qanday rasm chizish kerak" degan ko'rsatmalar to'plami. Xuddi shef oshpazga retsept berganday. Har safar ekran yangilanganda (scroll, animatsiya, ekran o'lchami o'zgarishi), telefon o'sha retseptni qaytadan o'qib, rasmni qayta chizadi. Bu ishni CPU bajaradi. Muammo qayerda? Kichik SVG — masalan ikonka — bu muammo emas. Lekin katta va murakkab SVG (500KB va undan yuqori) ichida minglab chiziqlar, murakkab yo'llar va gradientlar bo'ladi. Telefon sekundiga 60 marta shu "kodlarni" o'qib, rasm chizishga ulgurolmay qoladi. Natija? Scroll paytida qotish, FPS tushishi, batareya tez qurishi. Yechim nima? Katta hajmli SVG fayllarni PNG formatiga o'tkazing. PNG ni chizish uchun CPU emas, GPU ishlaydi — va GPU bu ishga juda moslashgan, deyarli kuch sarflamaydi. Qoida oddiy: SVG hajmi 10–20KB dan oshsa → PNG ishlatgan ma'qul. SVG — zo'r format, lekin katta va murakkab holatlarda u ilovangizni sekinlashtiradi. PNG esa kattaroq hajmga ega bo'lsa-da, chizish tezligi jihatidan ancha yuqori. To'g'ri formatni to'g'ri joyda ishlatish — bu oddiy qaror, lekin foydalanuvchi tajribasiga katta ta'sir qiladi. 🚀@ITwithBobur

Soo true.... Ko‘p junior devlar ishga kirgandan keyin birinchi qiladigan narsa — project haqida to‘liq docs so‘rash bo‘ladi. Lekin bu har doim ham real expectation emas. Aslida esa: - documentation ko‘p joyda to‘liq bo‘lmaydi - uning responsibility’i asosan team lead yoki project manager zimmasida bo‘ladi - yangi kelgan developerga esa darrov 100% ishonch berilmaydi Bu normal holat. Chunki jamoa seni hali “sinovdan o‘tayotgan” odam sifatida ko‘radi, tayyor tizimning egasi sifatida emas. Shu sababli ham hamma narsa sekin-sekin beriladi: kichik tasklar, code review, tizimni tushuntirish. Ko‘p juniorlar esa 1 haftada: “menga yetarlicha ishonishmayapti, men bu jamoaga mos emasman” degan xulosaga kelib, tezda chiqib ketadi. Aslida esa bu bosqich — adaptatsiya davri. Ishga kirish — “hamma meni oiladay qabul qiladi” degani emas. Bu — “men o‘zimni isbotlaydigan jarayon” deganidir. Eng muhim narsa: tez xafa bo‘lish emas, tizimni tushunishga vaqt berish. 🚀 @ITwithBobur

Assalomu Alaykum, bugungi postimda men Mobile ilovlar bilan ishlashda Ai ni qo‘llash bo‘yicha fikrlarimni bo‘lishmoqchiman. Ohirgi paytlarda Ai bilan kod yozish urfga aylandi, o‘zim ham jarayonni tezroq bajarish uchun Ai dan foydalanishga o‘tganman. Faqat o‘zim uchun ba‘zi qoidalarni tuzib olganman. 1. To‘g'ri promt yoza bilish. Agar prompt to‘g‘ri va aniq bo‘lsa ishlar zo‘r, lekin kamchilik bo‘lsa hech qachon siz o‘ylagan feature ingizni to‘g‘ri implement qila olmaysiz. Masalan Avtorizatsiya uchun login flow tuzib ber deyishni o‘zi bu juda common prompt. Ai bu berilgan commentga qarab eng ommabop login strukurasini tuzib beradi. Feature dan kelib chiqib aniq promot bering. 2. Ai yozgan logikani avval o‘zim review qilaman, agar kod menga yoqmasa shunchaki uni qabul qilmayman. Yoqmasa deganda kod loyiha arxitekturasidan chiqib ketsa, Ai qilgan logika haddan tashqari tushunarsiz yoki tushunishga qiyin bo‘lsa. 3. Ai bilan kod yozilganda uni loyiha ichidagi qaysi filelarga o‘zgarish qilgani haqida aniq bilish kk. Aks holda side effect berib butun bir loyiha productionda fail berishi mumkin, va bu katta ehtimol bilan o‘ylamagan va oldin ishlab turgan qismidan bo‘lib chiqadi. 4. Ai bilan ishlaganda Agentga loyiha strukturasini o‘qitib llm.md qoidalarini tuzib olish kerak. Nega? Sababi Ai promptni bajarishda o‘sha qoidalarni eslab qolgan va undan tashqariga chiqmagan tartibda ishlaydi. 5. Mobil dasturchi sifatida figma/adobe design prototype lar bilan ishlaymiz, agar yangi loyiha bo‘lsa avval bir nechta screenlarni qo‘lda yozib o‘zingiz tartibli deb bilgan arxitekturaga moslab olishingiz kerak, undan keyin uni Ai ga o‘qitib qoidalarni tuzib olish kerak. Keyingi design qismlarini MCP service ga chizdirib davom etsangiz xatolik kamroq va siz o‘ylagandek yoza boshlaydi.

abstract interface class AuthDataSource { Future<Either<Failure, AuthResponse>> login({required AuthRequest request}); } @LazySingleton(as: AuthDataSource) class AuthDataSourceImpl implements AuthDataSource { final Dio _dio; AuthDataSourceImpl({required Dio dio}) : _dio = dio; @override Future<Either<Failure, AuthResponse>> login({ required AuthRequest request, }) async { try { final response = await _dio.post("", data: request.toJson()); log("Response data: ${response.data}"); return Right(AuthResponse.fromJson(response.data)); } on DioException catch (error, stacktrace) { log("Exception occurred: $error stacktrace: $stacktrace"); return Left<Failure, AuthResponse>( ServerError.withDioError(error: error).failure, ); } on Exception catch (error, stacktrace) { log("Exception occurred: $error stacktrace: $stacktrace"); return Left<Failure, AuthResponse>( ServerError.withError(message: error.toString()).failure, ); } } } abstract interface class AuthDataSource │ │ │ │ │ └─ Dart: "bu class" │ │ │ └─ "Faqat implements qil, extends QILMA" │ └─ "Instance yaratma, faqat shablon" Dart 3 da kodni sifatini boshqarish uchun max imkoniyatlar yaratilgan .... https://t.me/devspaceuz

Dart 3 da class'ning qanday ishlatilishini nazorat qilish uchun kiritilgan modifaerlar Dart 3 versiyasida klasslarning qayerda va qanday ishlatilishini (meros olish, interfeys sifatida ishlatish yoki obyekt olish) aniq nazorat qilish uchun bir nechta yangi modifikatorlar kiritildi. Bu xuddi "bu klass bilan nima qilish mumkinligini" belgilovchi qoidalar to'plamiga o'xshaydi. Keling, ularning har birini ko'rib chiqamiz: 1. base class: Bu modifikator klassdan faqat meros olish (extends) mumkinligini bildiradi. Uni interfeys sifatida ishlatish (implements) taqiqlanadi. Maqsadi: Klassning ichki mantiqini va metodlarini saqlab qolish. Qoida: Uni meros olgan har qanday klass ham base, final yoki sealed bo'lishi shart. Dart base class Vehicle { void move() => print("Harakatlanmoqda..."); } // To'g'ri: Meros olish mumkin base class Car extends Vehicle {} // Xato: Interfeys sifatida ishlatib bo'lmaydi // class Bike implements Vehicle {} 2. interface class: Bu klassdan faqat interfeys sifatida foydalanish mumkinligini bildiradi. Ya'ni, boshqa kutubxonalarda uni extend qilib bo'lmaydi, faqat implements qilish mumkin. Maqsadi: Klassning tuzilishini (metodlar nomini) majburiy qilish, lekin uning ichidagi kodni meros bermaslik. Dart interface class Sharer { void share(String content) {} } // To'g'ri: Interfeys sifatida amalga oshirish class WhatsApp implements Sharer { @override void share(String content) => print("WhatsApp orqali: $content"); } // Xato: Meros olib bo'lmaydi (agar boshqa faylda bo'lsa) // class Telegram extends Sharer {} 3. final class: Eng qat'iy cheklov. Bu klassdan na meros olib bo'ladi, na uni interfeys sifatida ishlatib bo'ladi. U "yopiq" klass hisoblanadi. Maqsadi: Klass ierarxiyasini shu nuqtada to'xtatish va xavfsizlikni ta'minlash. Dart final class SecureVault { final String key = "1234"; } // Xato: Hech qanaqasiga foydalanib bo'lmaydi // class MyVault extends SecureVault {} // class MyVault implements SecureVault {} 4. sealed class Bu modifikator klassni abstrakt qiladi va uning barcha vorislari aynan shu faylning ichida e'lon qilinishi shartligini bildiradi. Maqsadi: switch operatorida barcha holatlarni tekshirish (Exhaustive checking) uchun ishlatiladi. Dart sealed class Result {} class Success extends Result { final String data; Success(this.data); } class Failure extends Result { final String error; Failure(this.error); } void handleResult(Result r) { // Switch barcha holatlar (Success, Failure) qoplangani tekshiradi switch (r) { case Success(): print("Zafar: ${r.data}"); case Failure(): print("Xato: ${r.error}"); } } 5. abstract class Klassik modifikator. Undan obyekt olib bo'lmaydi, faqat shablon vazifasini o'taydi. Dart abstract class Animal { void eat(); // Faqat nomi bor, tanasi yo'q } https://t.me/devspaceuz

Ilmalogiya play marketda productionga chiqdi. Shu furstadan foydalanib ota-onamga, oilamga, prezidentimizga... Uzr chalg'ib ketdim. Appni 30-dekabr kuni chiqargandik. Va 4 kun ketma ket updatelar ham bo'ldi. Play marketdagilar ham men ham yangi yilda dam olmadik. Play marketdan yuklab olib feedbacklarizlarni bersangizlar juda xursand bo'lardim: https://play.google.com/store/apps/details?id=uz.afsona_group.ilmalogiya Githubda ham ochiq turibdi kirib kodni review qilib bersangizlar ham xursand bo'lardim: https://github.com/ilmalogiya/ilmalogiya-mobile Kanal: @ilmalogiya ❤️🤫🏆

(5) Misol 1: int — value kabi ko‘rinadi (immutable) void main() { var a = 10; var b = a; // a bilan bir xil qiymatga "tenglashtirish" b = 20; print(a); // 10 print(b); // 20 } Nega a o‘zgarmadi? - b = 20 deganda siz `b`ni boshqa qiymat/obyektga bog‘ladingiz. - `int` immutable: `10`ni “ichidan o‘zgartirib” bo‘lmaydi, faqat yangi qiymatga o‘tasiz. Bu ko‘pchilikka “value type”dek tuyuladi. (6) Misol 2: List — reference farqi juda aniq (mutable) void main() { var a = [1, 2, 3]; var b = a; // b ham aynan shu list obyektni ko‘rsatadi b.add(4); print(a); // [1, 2, 3, 4] print(b); // [1, 2, 3, 4] } Bu yerda b.add(4): - `b`ni “yangi list”ga bog‘lamadi - bitta list obyektining ichini o‘zgartirdi - a ham o‘sha obyektga qarab turgani uchun, a’da ham o‘zgarish ko‘rindi Mana bu — reference semantikasi. (7) Misol 3: Custom class — reference semantikasi class User { String name; User(this.name); } void main() { var u1 = User("Ali"); var u2 = u1; u2.name = "Vali"; print(u1.name); // Vali print(u2.name); // Vali } u1 va u2 — bitta User obyektiga ishora qiladi. (8) “Unda men haqiqiy copy qilishni xohlasam-chi?” Reference turlarda (List, Map, class) ko‘pincha sizga copy kerak bo‘ladi. A) List uchun “shallow copy” var a = [1, 2, 3]; var b = List<int>.from(a); // yoki [...a] b.add(4); print(a); // [1,2,3] print(b); // [1,2,3,4] B) Lekin “deep copy” masalasi Agar list ichida yana list/obyektlar bo‘lsa, [...] faqat ustki qavatni nusxalaydi. Ichkaridagi obyektlar baribir reference bo‘lib qolishi mumkin. (Bu keyinroq memory leak/best practicesga ham borib taqaladi.) (9) Dart amaliyoti uchun 1) Dart’da o‘zgaruvchilar obyektga reference ushlab turadi. 2) Immutable obyektlar (int, String, bool …) sizga “value”dek ko‘rinadi, chunki ularni “ichidan” o‘zgartirmaysiz — qayta bog‘laysiz. 3) Mutable obyektlar (List, Map, Set, class fields) reference effektini chiqaradi: bitta obyektni ikki joydan o‘zgartirib yuborishingiz mumkin. 4) Shuning uchun state management, performance va bug’larning katta qismi: - “buni nusxa oldim deb o‘ylagandim, aslida reference ekan” - “buni o‘zgartirmadim deb o‘ylagandim, list ichini mutate qilibman” degan joydan chiqadi. 🚀 @ITwithBobur

2. Value vs Reference + Primitive vs Reference tushunchalari Dasturchilar ko‘p adashadigan joy: o‘zgaruvchi “ichida” qiymat turadimi yoki “qayerdadir” turgan obyektga ishora qiladimi? Shu savol “value vs reference” esa mavzusining yuragidir. Bu tushunchani to‘g‘ri anglasangiz, keyingi postlarda (call stack, heap, GC, leak) ancha oson bo‘ladi. (1) “Primitive type” degani nima? (umumiy dasturlashda) Ko‘p tillarda quyidagilar “primitive” deb ataladi: - int, double/float - bool - char (ba’zi tillarda) - ba’zan null yoki void bilan bog‘liq maxsus qiymatlar Primitive/value type g‘oyasi shuki: - o‘zgaruvchining o‘zida *qiymatning o‘zi* saqlanadi (masalan, 10). - nusxa olish (copy) qilinsa, *qiymat ko‘chirib olinadi*, bitta joyga bog‘lanib qolmaydi. Lekin: Dart’da rasmiy “primitive/value type” konsepti klassik C/C#/Java’dagidek emas. Dart’da hammasi “object” sifatida ko‘riladi (hatto int ham). Shunga qaramay, amaliy jihatdan int, double, bool, String kabi turlar bilan ishlash ko‘pincha “value-like” (qiymatga o‘xshab) ko‘rinadi, chunki ular: - immutable (o‘zgarmas) bo‘ladi, - siz ularni “o‘zgartirdim” deganda, aslida yangi qiymat/obyekt hosil bo‘ladi. Shu sabab postda 2 qatlamni ajratamiz: 1) umumiy nazariya: primitive/value vs reference 2) Dart amaliyoti: hammasi reference, lekin ba’zi obyektlar immutable bo‘lgani uchun “value kabi” tutadi (2) “Reference” degani nima? Reference — bu xotiradagi bir obyektning o‘rnini “ko‘rsatib turadigan” qiymat. Soddaroq tasavvur: - Obyekt — uy (heap’da turadi) - Reference — uyning manzili (address) - O‘zgaruvchi — mana shu manzilni ushlab turgan nom Shuning uchun reference bilan ishlaganda eng muhim narsa: - ikki o‘zgaruvchi bitta obyektga ishora qilishi mumkin - bittasi orqali o‘zgartirsangiz, ikkinchisida ham ko‘rinadi (agar obyekt mutable bo‘lsa) (3) Value vs Reference farqi: nusxa olishda (copy) nima bo‘ladi? # A) Value (qiymat) kabi ishlaganda Tasavvur qiling a = 10, b = a qilsak: - b — a ning nusxasi - keyin b o‘zgarsa, a o‘zgarmaydi # B) Reference kabi ishlaganda b = a qilsak: - b ham a ko‘rsatgan obyektni ko‘rsatadi - agar obyekt mutable bo‘lsa va siz uni o‘zgartirsangiz, ikkala o‘zgaruvchi “bir xil obyekt”ni ko‘rayotgani uchun natija bir xil bo‘ladi (4) Dart’da bu qanday ishlaydi? Dart spesifik g‘oyasi: - Dart’dagi o‘zgaruvchilar obyektlarga reference saqlaydi. - int, String ham obyekt (faqat VM optimizatsiya qiladi). - Shuning uchun “value vs reference”ni Dart’da ko‘proq shunday tushunasiz: - immutable obyektlar: “value kabi” seziladi (chunki o‘zgartirib bo‘lmaydi) - mutable obyektlar (List, Map, custom class): “reference effekti” yaqqol ko‘rinadi 🚀 @ITwithBobur

Data typelar 2 xil bo'ladi reference va primitive. Lekin dartda esa everything is an objectdegan prinsp bor. Tabiiyki savol paydo bo'ladi: Hamma narsa object bo'lsa shunda dartda primitive typelar ham object bo'ladimi? Demak dartda primitive type mavjud emas shundaymi?

1. Xotira nima va dastur qanday ishlaydi Dastur yozganimizda biz aslida kompyuterga: “mana bu ma’lumotlarni saqla, ularga ishlov ber, natijani qaytar” deb buyruq beramiz. Bu jarayonning markazida xotira (memory) turadi. Xotira — dastur ishlayotgan paytda ma’lumotlar vaqtincha saqlanadigan joydir. 1) Xotira deganda nimani tushunamiz? Kompyuter xotirasi (RAM) — juda tez ishlaydigan “ishchi stol”. Dastur ishga tushganda: - kod (instruksiyalar) yuklanadi, - o‘zgaruvchilar va obyektlar uchun joy ajratiladi, - hisob-kitoblar qilinadi, - natijalar qaytariladi. Xotira ichida ma’lumotlar bit/byte ko‘rinishida turadi. Ammo dasturchi sifatida biz “byte”lardan ko‘ra, o‘zgaruvchi (variable), obyekt (object), funksiya (function) kabi tushunchalar bilan ishlaymiz. 2) Dastur qanday ishlaydi? Dastur ishga tushganda quyidagi zanjir sodir bo‘ladi: 1. Source code (siz yozgan Dart kod) 2. Dart VM / AOT compiled (kod bajariladigan ko‘rinishga keltiriladi) 3. CPU instruksiyalarni bajaradi 4. Memory (RAM) dan o‘qiydi/yozadi 5. Kerak bo‘lsa, GC (Garbage Collector) ishlaydi (ortiqcha obyektlarni tozalaydi) Flutter/Dart’da bu jarayon ko‘pincha Dart VM (debug/profilingda) yoki AOT (release buildda) orqali boshqariladi. 3) O‘zgaruvchi nima? U xotirada qanday turadi? void main() { int a = 10; print(a); } Bu yerda a — o‘zgaruvchi, 10 — qiymat. Muhim fikr: o‘zgaruvchi bu “quti” emas, ko‘proq “nomlangan bog‘lanish (binding)” deb o‘ylang: - u xotiradagi ma’lum bir qiymat/obyekt bilan bog‘lanadi, - keyin bu bog‘lanish o‘zgarishi mumkin. Dart’da int, double, bool kabi turlar *primitivega o‘xshab* ko‘rinsa ham, Dart konseptual jihatdan hammasi object sifatida qaraladi (amaliyotda VM optimizatsiya qiladi). 4) Obyektlar va “heap”ga kirish (hali chuqurlashmaymiz) Dart’da ko‘p narsa obyekt: void main() { var name = "Dart"; var list = [1, 2, 3]; } - "Dart" — String obyekt - [1,2,3] — List obyekt Bunday obyektlar odatda heap deb ataladigan xotira qismida yashaydi. (Hali “Stack vs Heap”ni batafsil yozaman.) 5) Dastur bajarilishidagi “flow”: funksiya, stack va vaqtinchalik xotira Dastur doim bir nuqtadan boshlanadi — main(). Har safar funksiya chaqirilganda: - uning parametrlari, - lokal o‘zgaruvchilari, - qaytish manzili kabi ma’lumotlar vaqtincha saqlanishi kerak bo‘ladi. Bu odatda call stack orqali amalga oshadi. (Hali buniyam chuqur ochamiz.) 6) Nega bizga bu mavzu kerak? Xotira haqida tushuncha bo‘lmasa, quyidagilar “sirli” ko‘rinadi: - Nega ba’zi kodlar sekinlashadi? - Nega ba’zan “OOM” (out of memory) bo‘ladi? - Nega List katta bo‘lsa, performance pasayadi? - Nega “memory leak” yuz beradi? - Nega Value vs Reference farqi muhim? Bu seriyada biz aynan shu savollarga bosqichma-bosqich javob beramiz. - Xotira — dastur ishlayotgan paytda ma’lumotlar saqlanadigan joy. - Dastur CPU + memory bilan doimiy “o‘qish/yozish” qiladi. - Dart’da ko‘p narsa obyekt sifatida ishlaydi; VM xotirani boshqaradi va GC ortiqcha obyektlarni tozalaydi. - Keyingi mavzularda biz bu tushunchalarni aniq mexanizmlar bilan bog‘laymiz. 🚀 @ITwithBobur

Menda ikkita kod bor. Savol qaysi biri ko'proq yashaydi va nima uchun to'xtab qoladi? A: void main() { count(1); } void count(int n) { print(n); count(n + 1); } B: void main() { int n = count(1); for (;;) { n = count(n); } } int count(int n) { print(n); return n + 1; }

Kimdur: Yana qachon yaxshiroq mavzuda post chiqadi? Man:

Hozir AIga qant beraman deb aldasayiz bitta startupni mvp darajada bemalol ko'tarib beryabdi. Kim qanaqa AI ishlatyabdi? Ayni paytda qanaqa AI based editorlar yaxshi ishlayabdi? Men bilganlar biri claudeni maqtaydi biri cursor deydi yana biri AIni qoralaydi yana non bir tiyin edi deb qoyadi (qo'pol xazilmga omanglar buni sal bortirdim) rasm