Backend dasturchi do'stlarimga bir narsaga havasim keladi: prodda bug chiqsa, fix qilib 10 daqiqada deploy qilishadi va hammasi joyiga tushadi.
Mobil dasturlashda unaqa emas. Ilova foydalanuvchi telefoniga tushdimi, u endi sizniki emas.
Bug topdingiz, fix qildingiz, build yig'dingiz. Keyin App Store review'ni kutasiz. Bir kun, ba'zan ikki kun. Chiqdi deb xursand bo'lasiz, lekin foydalanuvchining yarmi baribir yangilamaydi. Kimdir auto-update'ni o'chirib qo'ygan, kimdadir xotira to'lgan, kimdir esa "shu ham ishlayapti-ku" degan tamoyil bilan yashaydi. Natijada o'sha bug yana bir necha oy kimningdir telefonida yashashda davom etadi.
Shuning uchun mobil dasturchi uchun eng qimmat bug bu foydalanuvchi qo'liga yetib borgan bug. Bundan kelib chiqadigan xulosalarim:
• Feature flag'siz katta narsa chiqarmaslik. Backend'dan o'chirib qo'yish imkoni bo'lsa, tunda tinch uxlaysiz.
• Force update mexanizmi birinchi relizdanoq bo'lishi kerak. Keyin qo'shaman desangiz, eski versiyadagilarga yetib bormaydi.
• Crashlytics'ni release'dan keyin emas, oldin sozlash. Xato haqida foydalanuvchining 1 yulduzli sharhidan bilish yoqimsiz tajriba.
• Staged rollout: avval 5–10%, jim bo'lsa keyin hammaga.
Ha, backend'chilar serverni yiqitsa ham hamma ko'radi. Lekin ular hech bo'lmasa uni o'zlari ko'tara olishadi. Biz esa foydalanuvchidan "iltimos, yangilab qo'ying" deb yalinamiz))
@devspaceuz

"Qaysi state manager eng yaxshisi?"
Intervyularda ham, chatlarda ham eng ko'p beriladigan savol. Bloc, Riverpod, Provider, GetX...
Mening javobim ko'pchilikka yoqmaydi: jamoangiz yaxshi biladigani eng yaxshisi.
Loyihani o'ldiradigan narsa noto'g'ri tanlangan state manager emas. Bitta loyihada uch xil yondashuv aralashib ketgani o'ldiradi. Bir ekran Bloc'da, boshqasi setState'da, uchinchisi yangi kelgan dasturchi yoqtirgan kutubxonada.
Tanlashdan oldin o'zingizga uchta savol bering:
• Yangi dasturchi buni bir haftada o'rgana oladimi?
• Buni test qilish osonmi?
• 2 yildan keyin ham qo'llab-quvvatlanadimi?
Kutubxona emas, izchillik loyihani tirik saqlaydi.
@devspaceuz

Bir xaftalik instagramga kiripmam uje

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

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

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

Dasturchilar o'zi introvert bo'lib tug'iladima yoki u vaat o'tib introvertga aylanadima ?
@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