Flutter Dev | Uzbekistan 🇺🇿

Yaxshi praktika! Oddiy lekin koʻpchilik ahamiyat bermaydigan "oshiqcha" ish... @flutterblogs

Is domain driven design (DDD) really worth it? Or is it just to create buzz? I’ve read two famous books on DDD. And as a team we got DDD trainings from “experts”. I can say, it is like philosophy. There are lots of buzzwords, ideas are not clear, implementation is not clear. It is against YAGNI principle, because you need to create lots of layers and code becomes hard to read. It requires lots of development time and hardware. None of the big technology companies have presentation about DDD. It is popular among consultants, because they have a new thing to sell. Everything looks good on presentations. “Ubiquitous Language”, even the term is not clear. Why it is not “Explicit Language”? And the books are full of new terms. In every page you see a new term. When you criticize DDD, advocates say it is about team dynamics, project management, business first thinking… For me DDD is a vague concept, full of terms, lots of marketing promises and consultants love it. Until some team from Facebook, Google, Amazon, Apple, Twitter uses DDD and achieve good results, I prefer to ignore it. === Domain Driven Design simply provides strategic and tactical methods for building business software. In some situations, it can help. In some situations, it can not help. In some situations, it might help but be too expensive. In some situations, you absolutely need to use it. In your particular example, you seem to have a situation where DDD could help but it would be too expensive to apply; so, I suspect you don’t have very complicated business rules. DDD pays dividends when you have an application with sophisticated business rules that need to be consistent close to 100% of the time. An anemic data model will scatter the domain logic/algorithms all over the place. This makes an anemic data model very expensive to maintain and very error prone when changing. Imagine having to update code in 50 different places for a single change request, and you have no formal means of guaranteeing correctness. That is not the kind of code you want when the business is constantly changing and trying out new things. However, when you start moving more behavior toward “aggregates” and away from the “boundaries” then changing code becomes less risky. Defining the “invariants” of your application with “aggregates” and “value objects” makes talking, reasoning, and testing the expected behavior of your system much easier. This is what gives DDD its competitive advantage. You have to determine if and when it makes sense to use it on a case by case basis. === AnemicModel is not the first thing to consider. DDD addresses more important issues first; DDD is about abstracting domain logic from technological aspects. "Manager/helper" classes generally contains application/service layer dependencies such as db query, transactions, logger etc. If so, they are not domain objects. When both application and domain requirements are complex enough, this approach will most likely to suffer in terms of maintainability and extensibility. I can suggest you ask yourself the following questions: Can I use my current domain objects directly(see open-closed principle) in totally different application requirements? (Using same domain.dll/jar on minimal in-memory db using mobile app for instance) Can I write test on any of those manager/helper classes without mocking/stubbing any dependencies? If both answers are yes, you're right, not that bad. You only have a AnemicModel problem. It is more about object purism discussion. [REFERENCE] @flutterblogs

За последние несколько дней канал вырос на космические 20% подписчиков, потому что я попал в папку с каналами по флаттеру (ещё есть чаты). Рад всех тепло поприветствовать ☺️ Теперь нас больше 500 человек! 🤔 Я сначала хотел написать новый пост-приветствие с рассказом о себе, но потом перечитал первый пост в канале и понял, что я всё равно написал бы то же самое, поэтому давайте оставим единый источник правды. Но есть ещё одна вещь, которую я осознал совсем недавно 🤔 Образовательные и технические материалы мы в Яндексе и так готовим много и регулярно: Flutter Handbook и Школы Мобильной Разработки (кстати, не забывайте податься в этом году), выступления на конференциях и чтение курсов в вузах — у нас на счету уже Иннополис, МФТИ, ВШЭ, Сириус и Бауманка. А вот здесь, на канале, я больше тяготею к развлекательному контенту по флаттеру: вкинуть холиварный опросик, поностальгировать, похайпить, поэкспериментировать, потравить анекдоты или помучать нейронки. Но, я так думаю, вы тоже не целыми днями продуктивно живёте эту жизнь, так что развлекательный контент по флаттеру лишним не бывает — всё-таки в интернет мы заходим сами знаете за чем 🚬 https://t.me/flutterbro

Ko‘p mijozlar bilan ishlab ushbu muammolarga duch keldim. Bu muammolar mendan boshqa ko‘plab mutaxassislarda bor deb o‘ylayman. Shuning uchun bu mavzuni ko‘tarishga qaror qildim.  Har doim muammo o‘zimizda deb o‘ylayman. Boshqalarni ayblash bilan hech narsa o‘zgarmaydi.  Mijozlar bilan bo‘lgan munosabatlardagi muammolar va shaxsiy yechimlar:  1. Pulni vaqtida bermaslik  Ko‘p mijozlarimda pulim qolib ketgan, bunga aybdor ham o‘zim. Bu takrorlanmasligi uchun — doim eng kamida 50% boshlang‘ich to‘lov bilan ishlaymiz — boshlang‘ich to‘lov sanasini oldindan aniqlaymiz  — qolgan to‘lovni aniq sanasi va vaqtini oldindan kelishamiz.  — Bu ish boshlashdan avval mijozga tasdiqlatib olamiz.  — Mijoz pulni bermasa — boshqa mutaxassislarni u mijoz bilan ishlamasliklari uchun ogohlantirib chiqamiz.  2.  Aniq texnik vazifasiz ishlash  Ish boshlashdan avval 3 kunlik ish, ammo ish boshlangandan keyin bu ish bir necha oyga cho‘zilib ketgan vaziyatlar bo‘ldi. Bu yerda ham o‘zim aybdorman.  — Ishni boshlashdan avval qancha vaqt ketishidan qatʼiy nazar qilinishi kerak bo‘lgan ishlarni ro‘yxatini tuzib chiqish kerak.  — TV (texnik vazifa) dan kelib chiqib loyihani aniq narxini belgilaymiz  — Loyiha qachon tugatishini aniqlaymiz  — ish cho‘zilishi mumkin bo‘lgan holatlarni ko‘rib chiqamiz  — ular maʼlumot beradigan holatlarda aniq sanasini belgilaymiz  — uchrashuvlarni kuni va vaqtini oldindan belgilaymiz  — texnik vazifadan tashqari narsalar qo‘shilishi mumkin bo‘lsa ularni narxlarini belgilaymiz  3. Qo‘shimcha ish uchun haq to‘lamaslik  Ish boshlanadi, TVʼga kiritilmagan ko‘plab vazifalar chiqadi. Shunday holatda u vazifalarni qilmasdan avval buning uchun haq olinishini eslatib o‘tish kerak bo‘ladi. Qo‘shimcha ishlar deadline cho‘zilishiga olib kelishi va bu narxga taʼsir qilishini aytish kerak. Aniq yakuniy deadline va sanalarni aniqlashimiz kerak bo‘ladi.  4.  Mutaxassislarga xodimdek qarash  Mutaxassis buyurtmachining xodimi emas. Uning o‘zining ish grafigi, ish joyi va shartlari bor. Ko‘p xollarda mutaxassisdan doim online bo‘lish, uchrashuvlarda qatnashish yoki shunga o‘xshash talablar qo‘yiladi. Bu masalalarni ish boshlashdan avval aniqlab olish kerak.  — nechta uchrashuv bo‘ladi? Qachon, qayerda va qaysi sanada?  — qachon siz xabarlarga javob yoza olasiz?  — qachon xabarlarga javob yoza olmaysiz?  — qaysi kunlari siz ishlamaysiz? — Sizning vazifalaringizga nimalar kiradi? Aniq ro‘yxatini ko‘rsatish kerak.  5. “Deadline” loyihani tugatish uchun belgilangan vaqt o‘tib ketishi  Manda juda ko‘p deadlineʼlar o‘tib ketish holatlari bo‘lgan. Mijozlarim xabarni o‘qiyotgan bo‘lsa uzr so‘rayman. Bu narsani o‘zim xohlamaganman, ammo shu xolatlar ko‘p kuzatilgan. Loyiha olayotgan paytimizda birinchi navbatda o‘zimiz uchun «deadline» aniqlaymiz. So‘ng shu «deadline»ga yana eng kamida 30% vaqt qo‘shamiz va shu vaqtni mijozga aytamiz. Shunda zaxirada yetarlicha vaqtimiz qoladi.  — Ishni esa shu belgilangan vaqtga yoyib yuboramiz.  — Aniq har kuni shu loyiha ustida ishlash uchun vaqt belgilaymiz  — Loyiha uchun timer qo‘yamiz  — Masʼuliyatni his qilishimiz kerak.  6. Ishni oqibatida do‘stlik rishtalarini uzilishi Do‘stlar bilan ishlash zo‘r. Ammo barcha yuqoridagi qoidalarga amal qilmaslik oqibatida ko‘p do‘stlardan ayrilish mumkin.  Yuqorida o‘qiganingizning nomi (SOP — Standart Operation Procedures). Xuddi shunday qo‘llanmalarni biznesning har bir jarayoni uchun yozib chiqish kerak. Prototype agentligimiz va Shogirdlik dasturida saytlar bilan bog‘liq 10 ga yaqin jarayonlar uchun shunday qo‘llanmalarni ishlab chiqishni boshladik. Siz qanday qoidalarni ishlatasiz? Sizda ham shunday muammolar bormi? © Umid Ikromboev @flutterblogs

#serverpod 🧑‍💻 Serverpod'da modellarni umuman qo'lda yozmaysiz! Shunchaki server/models/ folderni ichida .yaml formatida o'zingizga kerakli model haqida ma'lumotlarni kiritasiz va birgina

"serverpod generate"

buyrug'i orqali modellarni osongina generate qilib olasiz. Yuqorida esa .yaml va tayyor .dart model fayllar ko'rsatilgan. 🧑‍💻 Flutterda shunga o'xshash qanday servislarni bilasiz? Manba: t.me/ahadjonovss

If comment is there to explain the code to the coder... @flutterblogs

👨‍💻 Agar meni yollamoqchi bo'lsangiz, murojaat eting / If you wanna hire me contact: @mamasodikoff 🕑 Ish vaqtim / Working hours: 07:00 pm - 23:00 pm 🗓 To'liq ish kunlarim / Full working days: Shanba-Yakshanba/Sat-Sun 🛠 Mening mahoratlarimni quyida ko'rishingiz mumkin / You can see my skills here: https://www.upwork.com/freelancers/~01ce72ad205e2526e5 ⏰ My Approximate Timeframes: Simple Complexity App: UI/UX Implementation: 40-50 hours Backend Integration: 30-40 hours Testing and Bug Fixing: 15-35 hours Deployment and Launch: 10-15 hours Total estimated time: 95-140 hours Mid Complexity App: UI/UX Implementation: 60-80 hours Backend Integration: 50-90 hours Testing and Bug Fixing: 20-30 hours Deployment and Launch: 10-15 hours Total estimated time: 140-215 hours High Complexity App: UI/UX Implementation: 80-120 hours Backend Integration: 70-100 hours Testing and Bug Fixing: 20-30 hours Deployment and Launch: 10-15 hours Total estimated time: 180-265 hours #freelance #open @flutterblogs

#tool 🧑‍💻 Loyihadan keraksiz “import” larni olib tashlash uchun yuqoridagi command’dan foydalaning.

dart fix --apply --code=unused_import

Manba: t.me/ahadjonovss

Premium bo'lsa "boooost" 🚀 ni bosingiz! Duo qilaman, Flutterda kirmoshinaga ham kompilyatsiya qila oladigan bo'lasiz!) https://t.me/boost/flutterblogs

Kanaldagi postlar xaritasi. Albatta, Doimiy yangilab boriladi. 1. Flutterda GestureDetector va InkWell farqlari. 2. Dartda Var, Final va Const haqida. 3. Flutterda dastur kompilatsiya bo'lish jarayoni. 4. Dart-ning JIT va AOT kompilyatorlari haqida qisqacha. 5. Flutterda Widget hayot sikli (lifecycle) haqida. 6. Flutter App lifecycle haqida. 7. Dartda Izolyatsiya (Isolate) va Oqim (Thread) farqlari. 8. Dartda Isolate.spawn() va Isolate.run() farqlari. 9. Bloc Widget-lar haqida. 10. Flutter-da ListView va ReorderableListView farqi. 11. Flutterda main() va runApp() funksiyalar farqi. 12. Flutter-da "mounted" property haqida. 13. Flutterdagi tree (daraxt)-larning farqlari (Widget, Element va Render Object). 14. Dart dasturlash tilida Constructor turlari. 15. Dart-da Cascade operator haqida. 16. Dart-da copyWith() metod haqida. 17. Flutter-da LayoutBuilder widget haqida. 18. Spread operator haqida. 19. Dartda typedef kalit so'zi haqida. 20. Flutterda await va Future.wait farqi. 21. Dart-da Iterable class haqida. 22. Dart-da Iterable metodlari (1-qism). 23. Dart-da Iterable metodlari (2-qism). 24. Dart-da Iterable metodlari (3-qism). 25. Dart-da Iterable metodlari (4-qism). 26. Dart-da Iterable metodlari (5-qism). 27. "WidgetsFlutterBinding.ensureInitialized" o'zi nega kerak ? 28. Flutterda Memory Leak haqida qisqacha. 29. Flutterda BuildContext haqida. 30. Dartda Generic haqida qisqacha. 31. Flutterda funksional xatoliklarni boshqarish. 32. Flutterda Getit yordamida bog’liqlikni davolaymiz. 33. Dartda Sealed class haqida. 34. Flutterda orientatsiya o'zgarishlarini aniqlash. 35. Dartda "static" kalit so'zi haqida. 36. Dartda "mixin", "mixin class" va "abstract mixin class" haqida. 37. Flutterda Stack va IndexedStack vidjet haqida. 38. Flutterda Screenshot olishni taqiqlash. 39. Flutterda Expanded, Flexible va Spacer vidjetlar haqida. 40. Flutterda Wrap vidjet haqida. 41. Flutterda “Key” turlari haqida. 42. Flutterda Freezed package haqida. 43. Flutterda matn hajmini o'zgarmas qilish. 44. Dartda Stream turlari haqida. 45. Dartda "dynamic" kalit so'zi haqida. 46. Flutterda "runZoned" va "runZonedGuarded" funksiyalari haqida. 47. Flutterda ErrorWidget haqida. 48. Flutterda ValueListenableBuilder va ValueNotifier vidjetlar haqida. 49. Flutterda InteractiveViewer vidjet haqida. 50. Flutterda Debounce va Throttle haqida. 51. Dart-da AsyncMemoizer class haqida. 52. Flutterda animatsiya turlari. 53. Flutterda moslashuvchan (responsive) UI. 54. Flutterda "DeepCollectionEquality" class haqida. 55. Dartda Reference, Shallow va Deep copy-lar haqida. 56. Flutterda Render engine haqida (Skia vs Impeller).

Flutterda yuzni aniqlash uchun loyiha qildim 👁👄👁 Yuzni solishtirish muammo emas, lekin passiv jonlilikni aniqlash qiynamoqda, biroz progress bordek tuyulgandi, lekin ancha nostabil variantdan ketibman. Oddiygina kulish va ko'zni yumish harakatlarini kuzatish uchun kod yozmoqchiman endi. Agar "contribute" qilishni istasangiz mana repo: https://github.com/Mamasodikov/FaceRecognitionLivnessDetection (Research bo'lganligi sabab hozircha biroz spagetti yeymiz 🍝) #facenet #mlvision #tflite @flutterblogs

Yangi maqola 🎉 Link: https://flutterdev.uz/2024/04/11/rivojlanishingizni-kuchaytirish-uchun-flutterga-oid-5-ta-juda-foydali-tavsiyalar/ @flutterblogs

Dasturchining "подкат" li izhori qanday bo'ladi? (Inglizcha yozdim, sababi o'zbekchada mos tushmas va qiziq chiqmas ekan) Are you https? Because without you I'm just :// Are you https? Because without you I'm insecure Are you Java? ☕ Because without you I'm just a script.. Are you Python? 🐍 Because without you my life is full of syntax errors... Are you setState, because without you, I'm Stateless 💔 Are you Flutter? Because without you I can't point Dart 🎯 to your heart .. 💘 Are you hot reload/restart? ⚡ Because without you my life is so hard to run... I would share my Cookies with you but I'm not sure if you are token (taken)... Are you double? Because the thought of you always floats inside my head.. I stopped googling because i found you.. Are you WiFi, because without you i feel disconnected.. Are you a firewall, because without you I'm vulnerable If your DNA was programmed in C++, then you had pointers in my heart... And laaast one, Are you P in PHP, because without you I'm happy (HP) 😂 @flutterblogs

Ramadan is fading out... @flutterblogs

- Ilova Flutterda qilinganini qayerdan bilasan? - Shunchaki 2 ta barmog'ing bilan sur, surilish 1 ta barmoqqa nisbatan 2 marta tezroq bo'ladi :) Ha, bu Flutterni anchadan beri tuzatilmagan "bug" yoki "feature" si edi. Vanihoyat Flutter 3.19 da bu optsiya "default" holatda o'chirib qo'yildi. Agar istasangiz, qayta yoqib qo'yishingiz ham mumkin. @flutterblogs

✨Kanalimda lirik chekinish qilgan holda, no coding yo'nalishiga kiruvchi 3D modellashtirish sohasi bo'yicha o'z bilimlarimni ulashmoqchiman. 👩🏻‍💻🚀Bo'lib o'tgan "Digital generation girls" IT-campining 3D modellashtirish yo'nalishida ishtirok etib va boshlang'ich tushunchalarni o'rganib, ular orqali Blender muhitida bir qancha modellar yaratdim(yuqoridagi videolar orqali baho berishingiz mumkin👀), hamda albatta ularni mobil ilovalarda ham demo sifatida sinab kordim. 📲Agar flutterda 3D modellarni qo'llamoqchi bo'lsangiz, mana shu demo projectimdan foydalanishingiz mumkin (ko'p kishiga foydali bo'lsa xursand bo'laman😊). ✨I want to share my knowledge in the field of 3D modeling in the direction of no coding, making a lyrical retreat on my channel. 📲If you want to utilize 3D models in flutter, you can use this demo project of mine (I will be happy if it is useful to many people😊 ♻️Sharing is caring! © Just Android Blog kanalidan @flutterblogs

ARXIVDAN 📽 "VELOCITY"- Toshkent ko'chalarida "street racing" qiling! Year: 2014 @flutterblogs

RAD - Rapid Application Development - Tezkor ilova qurish texnologiyasi hisoblanadi. Hozirgi "Low code" larni RAD desa bo'ladi. Bu turdagi "development" ni bir qancha foydalari bor: - Dasturchi o'rganib, qilinishi aniq bo'lgan yechimlar avvaldan berilgan bo'ladi. Dasturchi endi shunchaki loyihalovchiga aylanadi. - Prototiplarni chiqarish bir muncha oson va tez bitadi, keyinchalik funksiyalarni kengaytirish ham mashaqqat tug'dirmaydi. Ushbu texnologiyani asosi sharshara modelining implementatsiyasi sifatida 70 - yillarga borib taqaladi. Texnologiya hammamizga mashxur "Embarcadero RAD Studio" da ham ko'rinish bergan. Lekin kompaniya texnologiyani juda sekin rivojlantirishi, sekin "update" lar chiqarishi, open source emasligi, kompyuterdan katta joy va resurs talab etishi, "performance" dagi kamchiliklar va shu kabi juda koʻp sabablar tufayli sekin sekin nazardan qoldi. Xullas, Microsoftning .NET i uni ustidan "ezib" ketdi. Lekin "low-code" va "no-code" platformalarga ehtiyoj ayni paytda yana kuchli impuls bera boshladi. Flutterni ham qaysidir ma'noda RAD desa bo'ladi, lekin bu qanday qarashga bog'liq. Chunki Flutterda istasangiz juda ichkarigacha "kira" olasiz. Istamasangiz, ehtiyoj bo'lmasa, yuzaki va tezlik bilan to'laqonli ilovalarni tayyorlay olasiz. Ha aytgancha, quyidagi videoda meni 1-yozgan video-o'yinim. 14 yoshimda, aynan RAD texnologiyasida qilingan :) @flutterblogs

👨‍💻 Dasturchilarga ham foydali bo'ladigan, ba'zi "Myorfining qonunlari" ga qarshi turish yo'riqnomasi 📑 💎 1. Hamma narsa sen oʻylagandek oson emas Yechim: Pozitiv pessimizim - hamma boʻlishi mumkin boʻlgan muammolarni oldindan oʻylab qoʻyish kerak. 💎 2. Har qanday ish sen oʻylagandan koʻproq vaqt oladi Yechim: Nimadir qilmoqchi boʻlsangiz ertaroq boshlashga harakat qiling yoki koʻproq vaqtni belgilab oling 💎 3. Boʻlishi mumkin boʻlgan eng yomon senariy boʻlish ehtimoli doim bor Yechim: Oldindan oʻylab qoʻyilgan muammolar ichida eng yomoni boʻlishi mumkin. Bunda shu muammoga turli yechimlar oʻylab tayyorlanib turish kerak. Muammo boʻlishiga ham tayyorlanib qoʻyish kerak. 💎 4. Agar boʻlishi mumkin boʻlgan yomon ishni 4 ta sababini bartaraf qilsang, 5-si paydo boʻladi Yechim: Bunda qilayotgan ishimizdan kutuvlarimizni katta qilib yubormasligimiz kerak. Doim B reja boʻlsin. 💎 5. Entropiya qonuni - har qanday oʻziga tashlab qoʻyilgan tizim yomonlashish xususiyatiga ega Yechim: Bir xonaga 1 oy kirilmasa chang bosib ketadi. Insonlar bilan ham shunday. Agar inson miyasini, oʻzini shugʻullantirmasa, yomonlashish xususiyatiga ega. Har doim oʻz ustimizda ishlashimiz kerak. 💎 6. Biror ishni qilishni boshlasang, undan oldin qilish kerak boʻlgan ish paydo boʻladi Yechim: Ishlaringizni puxta va tartibli rejalashtiring. Vaziyatni obyektiv ko'ra biling va prioritet bo'yicha bajaring. Bugungi ishni ertaga qo'ymang. Prokrastinatsiyadan qutiling. 💎 7. Har qanday qaror yangi muammolarni keltirib chiqarishi mumkin. Qaror qabul qilmaslik ham aslida qaror. Yechim: Biz qanday qaror qabul qilishimizdan qatʼiy nazar muammoga uchrashimiz mumkin. Bunda 1-qoidada aytilgandek muammoni oldindan oʻylab qoʻyish kerak. Hamda 4- qoidada aytilgandek kutuvlarimizni katta qilib yubormasligimiz kerak. Myorfi qonunlari: www.cse.unr.edu/~sushil/quotes.html @flutterblogs