Programming ∀

Farosat left E-imzo Bunaqa qilgandan nima foyda ? Eshikni qulfladingiz kalitni eshik ushlagichiga "ruchkasi" ilib ketdingiz... Eng qizig'i shu password ham noto'g'ri ekanligida )) To'g'risi qaysi ekan bunisini topolmadik )) Applarimiz TRASH zato osmonimiz musappo 👻 Davlat tashkilotlariga xalqni ishi tushganda maksimal darajada Zzz qilishadi... Bir savol berish kerak shu joyida )) Ushbu savolni nima ekanini topishni yoki o'ylashni o'zingizga qoldiraman 😀

Кимдир яхши дастурчи Ўзбекистонда 2000 олади, деб ёзиб қолади. Ҳозир концентрация қила олиб ишлайдиганлар сони жуда кам, деярли барча Фейсбук, Телеграм, тармоқлар, ютуб орқали зомбилашган, контент наркоманига айланиб бўлган. Фикрини жамлай олмайди, ақлий фаолиятни соатлаб давом эттира олмайди. Бир муаллиф айтгандек, одамлар “зависимый”, хаёли паришон, семиз бўлиб қолган (addicted, distracted, overweight). Кэл Ньюпортнинг “В работу с головой” (Deep Work) асарида айнан хаёлни жамлаб, хотиржамлик билан ақлий меҳнат қилиш муҳимлиги, айниқса ҳозирги замонда бундай инсонларга талаб ошиб кетганлиги ҳақида ёзилган. Шунинг учун, икки минг олиши фақатгина бир сон, аслида беш минг ҳам, саккиз минг ҳам олиб ишлаётганлар бор, нафақат дастурчилар, бошқа соҳадагилар ҳам. Ҳозирги замонда ақилли бўлиш дегани, фокусга эга бўлиш дегани.

Meyli trash markazlar va "coder"larni haterlik qilish xozircha otmen ishga o'tamiz ))). Hullas Yaqinda qilgan bir loyihamni to'liq I/O va perfomance diagnostic qilishni hohlab qoldim. Boshida shunday diagnostic tool yozib chiqish haqida ham o'yladim lekin yozib chiqishga vaqt yoq shu sabab linux o'zidagi prev_events toolini ishlatib qo'yaqoldim. U yerda juda kop ma'lumotlar va metrics monitoringlarni olsa bo'ladi. Havola: https://www.brendangregg.com/perf.html

Testlar Negadur ko'pchilik testlarni yozishni xoxlamaydi. Kop kompaniyalarda esa umuman testing masalasiga etibor qaratilmaydi. Bu borada tanqidiy hulosalar ko'p ammo bularni xozircha bayon qilmoqchi emasman. Xozir Testlardan nima manfat ko'rganim shu bilan birga qanday tajribalar qilganimni bo'lishimoqchiman. Testlar yozish masalasida eng avvalida integration va E2E testlardan boshladim taxminan 2 yil avval. Testlarni kop holatlarda talabga emas biror qilingan funksionalga qarab yozar edik. Xozirgacha kopchilik shunday o'ylasa kerak. Ammo minde o'ylab qarasam bu umuman foydasiz ekan ))). Test yozish emas yondoshuv yoki uslub xato ! Keyin qarashlar va olchovlar o'zgarib (Shakillanib) boshladi. Testlar haqida shaxsiy fikrlar paydo bo'la boshlagandan keyin talablar ham paydo bo'ldi yoki borlari o'zgardi. Keyin birqancha savollar qiynadi. 1. Testlar nima uchun kerak ? Test yozishda o'zi qanday yondoshuv kerak ? 2. Nima uchun Unit Testlar yozishim kerak axir Integration yoki E2E bundan ko'proq value beradiku ! 3. Nima sababdan dasturchi test yozishi kerak buni ana testerlar qilgani yaxshi... 4. Client test yozganimga pul bermaydi (( 5. Xop test yozaman ammo nimani testlashim kerak ? Aynan qayerda test yozish keragu qayerda yo'q 6. Test yozish jarayonida mocking qilish g'alatiku. Mock functional bilan real ishlashdagi farqli bo'lishi mumkin Bu savollarga javob topguncha ancha vaqt ketdi. Ammo javoblar xozircha qoniqtirdi va yangi savollar paydo bo'lmoqda ))). Demak javoblar. 1. Testlash va testlar yozish ortiqcha ish emas. Biz testlarda aniq requirementlarni belgilab izohlay olsak testlar ishimizni ancha osonlashtiradi shu bilan birga qilingan ish yoki functional requirementga qanchalik mos kelishini isbotlay oladi. Shu sababdan testlarni aniq requirementlarga qarab yozishimiz kerak va bu o'ta muhim ! 2. E2E va Integration testlar biror functionalni to'liq ishlayotganini tekshiradi. Yani barcha qismlar yaxlit qilib yeg'ilib bajaryaotgan ishini tekshiradi. Yani buyoqda jarayon abstract ammo natija muhim bo'ladi. (Jarayoni ham to'liq testlash mumkin ekani xaqida eshitganman ammo tajribada sinalgani yo'q xozircha) Unit testlar esa aniq maqsadga qaratilgan kichik qismlarni tekshiradi. Shu bilan bir qatorda Unit Testlar yozish orqali code yozishni ham o'rganvoman. Ayniqsa har Single Responsibilityga qattiq rioya qilish muhim. Bo'lmasa Unit Testlardan foyda yo'q. Agar codeda Unit Testlar bo'lsa va testable bo'lsa demak unday bo'lmaganidan ko'ra sifatli code bo'lish extimoli katta. Yani Unit Testlar bizga IDE darajasida muhim. 3. Testlarni dasturchi yozishi kerak. Chunki dasturchidan boshqasi qilgan ishiga javob bera olmaydi. Agar testlar yaxshi implement qilingan bo'lsa. Dasturchilar qilgan ishlarini testlar yordamida isbotlay oladilar (To'g'ri bu managementga umuman qiziq emas afsuski ). Ammo biz xatolarimizni clientdan yoki managerdan oldin topishimiz uchun ham test yozishimiz kerak. Testlar birinchi bug filter vazifasida ham bo'lishi mumkin. 4. To'g'ri client code yozganga pul to'laydi. Ammo clientga yozgan code aniq requirementlarga javob berayotganini isbotlash uchun ham testlar kerak. Buyoqda siz o'z ishingiz sifatini o'lchashingiz uchun ham test yozishiz kerak. 5. Testlashda eng muhim narsa testlar sizning qilgan ishingiz malum talablarga javob berish bermasligini aniqlash degan ekanmiz demak testlarni imkon qadar hamma joyda yozish kerak. Coreda ham oddiy kichik functionalarda ham. Yoki sodda bir maqsadli functionlarda ham. API darajasida ham. #testing #software_quality #quality

Xar doim dars qilayotib, Soxta “Biznes trening” videolarini ko’raman Chunki u videolar menga o‘qish qanchalik muhim ekanligini eslatib turadi... @Laimon_uz 🤓 PS: Manam ishlayotganimda yoki dars qilayotganimda o'quv markazlari haqida o'ylayman. Chunki kelajakda boshqalarga sifatli m'lumot ulashish kerakligini eslatib turadi ))

#goya #yechim Communitylarda offtopiclar va ortiqcha gaplar kopayib ketyabit... Shu sababdan mani taklifim huddi stackowerflowga oxshagan score system qilish kerak va barcha odamlarni scorelarini xisoblash kerak. Kimda score kam bo'lsa unga yozishiga cheklov qo'yish kerak masalan agar normadan past bo'lsa 10 minut intervalda yangi xabar yuborish mumkin. Guruhdagi activelik va uplar evaziga score oladi.

#goya #yechim Bizni davlatga yaxshi VCS dasturiy ta'minot kerak. Amaldorlarning barcha ishlarini user history qiladigan. Shu bilan birga muammolarni centeralized qilsa bo'ladigan. PS: Budjedan milliardlar ketib qolmasligi uchun shu g'oya haqida faqat xamkasblar o'rtasida o'ylab turaylik 😄

#OSS Open source software Ochiq kodli dastur yoki dasturiy taminot. Qiziq biz pulga kod yozamiz ammo tekinga olamiz... Birichi shu masalani yaxshilab o'ylab koraylik keyin ushbu maqolani davomini yozaman 😁

#foydali #oss Open Collective group or company. Ushbu tashkilot ochiq kodli dasturiy ta'minotlarni qo'llab quvvatlash bilan shug'ullanadi. Ushbu tashkilotdan qo'llab quvvatlash olib siz o'zingizni OSS loyihalarni monetization qilishingiz mumkin va bu juda ajoyib imkoniyat. Ammo tashkilotning o'ziga yarasha requirementlari mavjud. Agar kimdur open source loyihalarga contribute qilishni hohlasa yoki qiziqsa siz uchun qisman turtki bo'lar. Ammo asosiy turtki enthusiasm ))) https://opencollective.com/

#foydali Agar siz open source contributer bo'lsangiz yoki o'zingizni real open source loyihalaringiz bo'lsa jetbrains kompaniyasi sizga o'z productlariga free license beradi :) Batafsil: https://www.jetbrains.com/community/opensource/#support

Next level of copy pasting 🥲

Sen sen millatni sifatli Talim olishini hohlaysan, lekin doyim talimdan pul qilasan. @akhmadiy Albatta Najot talimda

ITdagi zluklar... IT kompaniya va hususiy tashkilotlarda bazi lavozim egalari bolmasa kompaniya yanada rivojlanadi. Vanihoyat shu mavzularda fikrlarim markazlashishni boshladi. Asosan turli managerlarni ornini avtomatlashtirish kerak. Ulardagi va dasturchilardagi fikrlar va qarashlar doyimo turlicha bo'lgan. — Ishga vaqtida kelishing kerak ! — Bizni kompaniyada masofaviy ish mavjud emas ! — Meetinglarda qatnashishing shart ! — Kompaniyaga sodiq bo'lishing kerak ! — Bu muhim emas ! Sizni ham shu kabi gaplar joningizga tegdimi ? Agar hali tegmagan bo'lsa demak engineer emasiz )) Managerlar clientdan yoki stackholderlardan kelgan gaplarni dasturchilarga yetkazadi... 1. Bu narsa absurtku stackholderlar puli bor aqli yo'q bo'lsa dasturchida nima ayib ? 2. Stackholderlar kopincha kop narsaga tupurib qoyadi va o'z pozitsiyasi va sohasini yaxshi bilmaydi. Aytaylik CTO agar CTO yaxshi Engineer bo'lgan bo'lsa engineerlar bilan muammo bo'lmaydi. U tizimni qanday ishlashini biladi. 3. CEOlarni katta qismi micromanagementni sevadi qandaydur tartibli odam yasavoladi ozidan )) Tartib har kimni ozini o'lchovida turlicha. Dasturchi: Kod tartibli bo'lsin shunda tartib bo'ladi loyiha sifati oshadi. Management: Ishchilar tartibli bo'lsin shunda boshqarish oson bo'ladi ishlar tezroq bitadi. Qarashlar kopincha mos kelmaydi. Lekin barcha productga boglangan. Aytaylik falon product ustiga shu jamoat yeg'ilgan. Shu sababdan mani nuqtai nazarim quyidagicha: Loyihaning o'zini talablari bo'lishi shart. Shu nuqtai nazardan qolganlar shunga moslashishi kerak huddi open sourcelar kabi )) Nodejs avtori loyihani support qilmay qo'ydi. Ammo Nodejs haligacha juda zo'r rivojlanyabti. Boshqa turdagi loyihalar ham aynan shunday rivojlana oladi va rivojlanyabti ! Man kerakmas deb bilgan positionlar: 1. Human resource manager(HR) 2. Scrum master 3. Project manager (PM) 4. Project owner 5. People manager Ushbu positionlar o'rnini avtomatlashtirish kerak. Bular doyim hissiyotlariga ishonib nimadurlar qiladigan kasb egalari deb bilaman. Bularni ishida obyektiv yondoshuv kerak ammo bu positiondagi koplab kishilar tor subyektiv oylab qaror qilishadi )))

ITdagi zluklar... IT kompaniya va hususiy tashkilotlarda bazi lavozim egalari bolmasa kompaniya yanada rivojlanadi. Vanihoyat shu mavzularda fikrlarim markazlashishni boshladi. Asosan turli managerlarni ornini avtomatlashtirish kerak. Ulardagi va dasturchilardagi fikrlar va qarashlar doyimo turlicha bo'lgan. — Ishga vaqtida kelishing kerak ! — Bizni kompaniyada masofaviy ish mavjud emas ! — Meetinglarda qatnashishing shart ! — Kompaniyaga sodiq bo'lishing kerak ! — Bu muhim emas ! Sizni ham shu kabi gaplar joningizga tegdimi ? Agar hali tegmagan bo'lsa demak engineer emasiz )) Managerlar clientdan yoki stackholderlardan kelgan gaplarni dasturchilarga yetkazadi... 1. Bu narsa absurtku stackholderlar puli bor aqli yo'q bo'lsa dasturchida nima ayib ? 2. Stackholderlar kopincha kop narsaga tupurib qoyadi va o'z pozitsiyasi va sohasini yaxshi bilmaydi. Aytaylik CTO agar CTO yaxshi Engineer bo'lgan bo'lsa engineerlar bilan muammo bo'lmaydi. U tizimni qanday ishlashini biladi. 3. CEOlarni katta qismi micromanagementni sevadi qandaydur tartibli odam yasavoladi ozidan )) Tartib har kimni ozini o'lchovida turlicha. Dasturchi: Kod tartibli bo'lsin shunda tartib bo'ladi loyiha sifati oshadi. Management: Ishchilar tartibli bo'lsin shunda boshqarish oson bo'ladi ishlar tezroq bitadi. Qarashlar kopincha mos kelmaydi. Lekin barcha productga boglangan. Aytaylik falon product ustiga shu jamoat yeg'ilgan. Shu sababdan mani nuqtai nazarim quyidagicha: Loyihaning o'zini talablari bo'lishi shart. Shu nuqtai nazardan qolganlar shunga moslashishi kerak huddi open sourcelar kabi )) Nodejs avtori loyihani support qilmay qo'ydi. Ammo Nodejs haligacha juda zo'r rivojlanyabti. Boshqa turdagi loyihalar ham aynan shunday rivojlana oladi va rivojlanyabti ! Man kerakmas deb bilgan positionlar: 1. Human resource manager(HR) 2. Scrum master 3. Project manager (PM) 4. Project owner 5. People manager

Sizga ham tegishli... Bo'lishi mumkin albatta

#time_to_think

Vaqt sarflashga arziydigan narsalardan biri ! Mongodb Driver. Source code yaxshiroq yozilgan ekan. Umuman olganda agar siz nodejsda standart ishardan boshqa hechnarsa qilib ko'rmagan bo'lsangiz. Masalan nodejs core modulelarda tajribangiz umuman bo'lmasa shu kabi loyihalarni ko'rib o'rganib chiqishni tavsiya qilaman. Juda yaxshi dunyo qarash beradi Mongodb Driver uchun link

#ashi_gap....

Kompyuter oldida o'lib ketishni hohlaganlar uchun...