Curious coder

Xozir bir tanish fizik aka bilan suhbatlashdim har qanday mexanik mexanizm kuchdan yutsa masofadan yutqazadi masofadan yutsa kuchdan yutqazadi dep tak shto san ielts olishing ham shunday protesesda .O'zing fiziku san nega yana boshni qotirasan deydila hayotinga tadbiq qil deydila , rostan xam shunaqaku boshqachi yo'q .
P/s: o'qish kerak... karl ...😂
@devspaceuz

0.1 + 0.2 = ?

Dart'da ishga tushirib ko'ring. Javob 0.30000000000000004 chiqadi.
Oddiy ilovada bu kulgili fakt. Fintech'da esa foydalanuvchi hisobidan "yo'qolgan" tiyin, keyin support'ga keladigan g'azabli xabar.
Sababi oddiy: double ikkilik sanoq tizimida saqlanadi va 0.1 ni aniq ifodalay olmaydi. Bitta amalda xato sezilmaydi, lekin minglab tranzaksiyada yig'ilib boradi. round() bilan yashirish ham yechim emas, muammoni faqat keyinroqqa suradi.

Pul bilan ishlaganda o'zimga qo'ygan qoidalar:

1)Summani eng kichik birlikda int qilib saqlash. 12 500,50 so'm emas, 1 250 050 tiyin.
2)Foiz, komissiya kabi kasrli hisob kerak bo'lsa, decimal paketi.
3)Backend bilan summani int yoki Stringda almashish. JSON'da kasrli son keldimi, Dart uni baribir double qilib parse qiladi.
4)Formatlash faqat UI'da, eng oxirgi qadamda.
5)Valyutani summa bilan birga saqlash. "100" degani 100 nima?
P/s: Kalkulyator ilovasi noto'g'ri hisoblasa kechirishadi. Pul o'tkazadigan ilova noto'g'ri hisoblasa, kechirishmaydi))
@devspaceuz

Hozirgi kunda IT sohasida raqobatbardosh bo'lib qolishning sanoqli yo'llarini ko'ryapman:
0)Low-level (quyi darajadagi) dasturlash tillarini o'rganish;
1)AI uchun ma'lumotlarni o'qitish (data training);
2)LLM modellarini yaratish.
Ochiqchasiga aytganda, boshqa yo'l ko'rinmayapti.
Anthropic va OpenAI kabi kompaniyalar hozir bizni shunchaki tinchlantirish bilan ovora, ammo yaqin 10 yillikda sohada qanday o'zgarishlar bo'lishi allaqachon aniq bo'lib ulgurdi. Kelajakda standart dasturchilar faqat tayyor yechimlar asosida tizimlarni qurish va System Design bilan cheklanib qolishadi xolos.
High-level (yuqori maoshli) pozitsiyalar uchun esa matematika va fundamental bilimlar hal qiluvchi rol o'ynaydi. Boshqacha qilib aytganda: Chiziqli algebra (Linear Algebra), Kalkulyus (Calculus), Differensial tenglamalar, hamda Algoritmlar va Ma'lumotlar tuzilmalarini (DSA) chuqur tushunish talab qilinadi.
Xullas, tayyor qismlardan arxitektura yig'ish kelajakda oddiy ishga aylanadi. Ammo tizimlarning "ichaklarida" nima yotganini tushunish, murakkab modellarni noldan yozish va haqiqiy qiymat yaratish uchun faqat matematika va kuchli fundamental baza kerak. Boshqa hech narsa qutqarmaydi.
p/s: Univerda o'quvchi bolajonlar shu fanlarni bosinglar endi o'quv markazga borishni foydasi yo'q
@devspaceuz

Dasturchilar o'zi introvert bo'lib tug'iladima yoki u vaat o'tib introvertga aylanadima ?
@devspaceuz

Kapot osti haqida gaplashamiz 🚙🚀 Impeller: Flutter nega Skia'dan voz kechdi?
Flutter ilova yozgan bo'lsangiz, bu holatni ko'rgandirsiz: ilova ochildi, hammasi silliq, lekin biror animatsiya birinchi marta ishga tushganda ekran bir lahza qotib qoladi. Ikkinchi safar esa hammasi joyida. Buning nomi shader compilation jank.
🧠 Muammo qayerda edi?
Ekrandagi har bir piksel GPU'da shader deb ataladigan kichik dasturlar orqali chiziladi. Skia bu shaderlarni kerak bo'lgan paytda, ya'ni runtime'da compile qilardi. Compile esa bir necha o'n millisekund oladi. 60 FPS uchun bitta frame'ga atigi ~16 ms ajratilgan, demak compile boshlandimi, frame'lar tushib qoladi va foydalanuvchi "qotish"ni ko'radi.
Flutter jamoasi buni SkSL warmup bilan yamashga harakat qildi: shaderlarni oldindan yig'ib, ilova bilan birga yuborish. Lekin bu noqulay edi, har qurilma va har yangilanishda ishonchli ishlamasdi.
⚙️ Impeller nima qildi?
Impeller muammoni yamamadi, uning ildizini olib tashladi:
• Shaderlar runtime'da emas, engine build qilinayotganda oldindan compile qilinadi. Ilova ishlayotganda hech qanday "birinchi marta compile" yo'q.
• Skia hamma uchun yozilgan umumiy kutubxona (Chrome, Android ham ishlatadi). Impeller esa aynan Flutter ehtiyojlari uchun yozilgan, shuning uchun shaderlar soni kichik va oldindan ma'lum.
• Zamonaviy grafik API'lar bilan to'g'ridan-to'g'ri ishlaydi: iOS'da Metal, Android'da Vulkan (eski qurilmalarda OpenGL ES).
• Natija: birinchi frame ham, minginchi frame ham bir xil tezlikda. Performance oldindan aytib bo'ladigan bo'ldi.
📅 Qachondan beri?
iOS'da Flutter 3.10 dan beri default, Android'da esa Flutter 3.27 dan beri (Vulkan qo'llab-quvvatlaydigan qurilmalarda).
💡 Nega bu muhim?
Rendering pipeline endi to'liq Flutter jamoasi nazoratida. Bu custom fragment shader'lar, murakkab effektlar va hattoki Flutter GPU orqali 3D kabi yangi imkoniyatlarga yo'l ochdi.
Xulosa: Skia tez edi, lekin har doim ham emas. Impeller esa har doim bir xil tez bo'lish uchun yaratildi. Foydalanuvchi uchun esa "o'rtacha tez" emas, aynan "qotmaydigan" ilova muhim))
@devspaceuz

Kod yozayotganda ko'pincha bitta narsani unutamiz: yozgan narsamizni oxirida kimdir ishlatadi.
Foydalanuvchi sizning arxitekturangizni ko'rmaydi. Qaysi pattern'ni tanlaganingiz ham, SOLID'ga amal qilganingiz ham uni qiziqtirmaydi. U faqat natijani ko'radi: tez ishlaydimi, ishonchlimi, kerakli ishini oson bajara oladimi.
Mahsulotni kod sotmaydi, tajriba sotadi. Sahifa yuklanishini kutib o'tirgan yoki tushunarsiz xatoga duch kelgan odam "ichida qanday chiroyli kod bor ekan" deb o'ylamaydi, shunchaki yopib boshqasiga o'tadi.
Foydalanuvchi ko'zi bilan qaraganda savollar boshqacha bo'ladi:
• Buni nega ishlatishim kerak? Qaysi muammoimni hal qiladi?
• Yuklama oshganda, sharoit yomon bo'lganda qanday ishlaydi?
• Maqsadimga necha qadamda yetaman?
• Xato chiqsa, nima ko'raman? "Something went wrong"mi yoki tushunarli yo'l-yo'riqmi?
Unda kod qanday yozilgani muhim emasmi? Muhim, lekin boshqa sababga ko'ra. Optimal ishlash mahsulotni bugun sotadi, toza yozilgan kod esa uni ertaga tirik saqlaydi.
Bugun yomon yozilgan kod ham ishlashi mumkin. Lekin bir necha oydan keyin yangi feature qo'shish bir haftalik ishga aylanadi, har fix yangi bug olib keladi, yangi kelgan dasturchi loyihani ko'rib qo'rqib qochadi)) Oxir-oqibat tizim sekinlashadi, relizlar kechikadi va foydalanuvchi baribir ketadi.
Xullas:
• Foydalanuvchi uchun tezlik va qulaylik muhim.
• Kod sifati o'sha tezlik va qulaylikni uzoq muddat saqlab qolish uchun kerak.
• Biri ikkinchisisiz yashamaydi: yaxshi kod yomon mahsulotni qutqarmaydi, yomon kod esa yaxshi mahsulotni sekin-asta o'ldiradi.
Kodni kompyuter uchun emas, odam uchun yozamiz. Bugun foydalanuvchi uchun, ertaga esa uni qo'llab-quvvatlaydigan dasturchi uchun.
@devspaceuz

Bu mani bir kun takrorlayman dep yurganim , lekin o'sha bir kuni qachon ligini bilmayman ...