Programming ∀

Syntax yoki texnalogiya qanchalik muhim ? Ko'pchilik yangi boshlagan xamkasblar tomonidan aytiladigan gaplardan bittasi syntax yoki biror tilga nisbatan biror narsani qilish haqida bo'ladi. Pythonda bunday qilsa bo'ladi... Javascriptda async funtionlar bor... Falon texnalogiyada falon narsalar qilsa bo'ladi... Shaxsan mani fikrim: Texnalogiyalar prioriteti albatta mavjud. Lekin eng yuqorida emas. Nimaga ? Xozirda man va juda ko'plab dasturchilarga yoqib borayotgan texnalogiya Rust. Ha Rust va bu ekotizim anchagina powerful ayniqsa memory management mavzularida. Rustda garbage collector yo'q. Undan tashqari Rustda juda tez computing yani tez ishlaydi. Undan tashqari unda immutability va ownershiplar juda zor qilingan. Yana Rustda macroslar bilan ishlash juda yaxshi qilingan. Shu sabab xozir system engineeringda ushbu ekotizim mashxurlashib boryabti. Yoki bo'lmasam Java, Juda ham ko'plab patternlar javadan tarqalgan. Shu sababdan Enterprise ecosystem ushbu tilni sevadi va ishonchli deb biladi. Yana javada OOPni tadbiq qilish imkoniyati yuqori. Java ekotizimi bunga anchagina qulayliklar taqdim qiladi. Elixir ham ajoyib til. Unda functional programming juda yaxshi realizatsiya qilingan. Elixir realtime applar qurish uchun umuman OTP boyicha juda zo'r ekotizimga ega. Shu sababdan judayam ko'p turdagi loyihalarda ishlatilingan va haligacha ishlatilinadi. Etibor qildingizmi ? 3 xil til haqida information berar ekanman asosan qandaydur terminlar, paradigm va prinsplar keltirildi. Undan tashqari yana malum domainlar ham aytib ketildi(OTP, System engineering, Enterprise) Agar falonchi kishi engineer sifatida sohaga aloqador umumiy narsalarni bilmasa demak u hali ancha sifatsiz engineer )) Biror bir narsani aynan falon til va syntaxga boglab organish ham nqzarimda notogri narsa. Masalan oddiy Command patternni implementatsiyasini korsan java va js da boshqa boshqa korinishda bolishi mumkin. Lekin pattern goyasi va masuliyati birxil boladi(agar togri implement qilingan bolsa ikkisida ham) Shu sabab aynan domain aspectlar juda muhim deb oylayman. Siz muammoga sifatli yechimni (arxitekturalash, dizayn va ilities) qilishni bilmasangiz dunyodagi eng zor texnalogiyada qilsangiz ham siz qilgan ish trash ekanicha qoladi )). Shu sababdan dasturlashdagi umumiy narsalarni ham yaxshiroq ham biror texnalogiyaga boglamagan holatda organish kerak. Texnologiyalar: Bu borada ham syntax kabi holat. Nodejs misolida olsak ko'pchilik aynan nodejs ecosystem bilan to'liq tanishib chiqmay turib juda eski gaplarni gapirishadi. 1. Nodejs faqat bitta threadda ishlaydi. 2. Nodejs da katta loyihalar qurib bo'lmaydi. 3. Nodejs vs <nimadur> Bunday gaplarni gapirish uchun odam: 1. Nodejsni anchadan buyon ishlatsa ham docsni juda kam ochib qaraydi. 2. Katta loyihalarda deganda uni o'lchovi buzulgan )). Chunki millionlab paralell requestlar yuboriladigan applar ham yozilgan nodejsda )) 3. Juniorlik sindromi ga chalingan yoki hali to'liq chiqib ketmagan. Barcha texnalogiyalarda umumiy va specefic feauturelar mavjud. Aynan umumiylari soni yuqori bo'lgani uchun ham ushbu texnalogiyalarga migration oson bo'lish extimoli katta. Agar sizda o'sha umumiy tushunchalar zo'r bo'lsagina )). Maxsus feauturelar aynan barcha tenxalogiyalarini bir biridan ajratib turadigan yana bir katta sabab. Shu sababdan ham texnalogiyalar va bir biriga alternativelar juda ham ko'plab topiladi. Biz bularni barchasini o'rgana olmaymiz. Yaxshi engineer bo'lish uchun biz asosan konsepsiyalar va domain aspectlarni yaxshi o'rganishimiz kerak. Ularni tadbiq qilshni esa albatta biz ishlatadigan ecosystemdan kelib chiqib qilamiz. Aynan o'sha qismda biz o'zimiz ishlatadigan texnalogiyani qanchalik yaxshi bilishimiz uning nozik nuqtalarini ham yaxshi farqlay olishimiz muhim bo'ladi. Hulosa o'laroq yan ba'zi fikr mulohazaolarimni share qilib ketmoqchiman.

File metadatalari rostdan ham anchagina qiziq ))

Actual masalalardan biri manashu.

Senga ilm berayotgan insonni hurmat qil! Gohida guruhlarda ko'rib qolamiz, kimdir savol beradi va u savoliga javob berilsa, "Buni man ham blama okya, mamini s6ravommanu" kabi qo'pol gaplar yozib qolishadi. Birinchidan, u odam senga javob berishga majbur emas. Senga vaqtini ajratib yordam berishga harakat qilyaptimi hurmatini joyiga qo'yib qo'y! Ikkinchidan, bilsang ham "rahmat aka tushunarli. Ammo men manabu narsani so'ragan edim." deb qo'ysang misqollab to'plagan yo'q obro'ing umuman yo'q bo'lib qolmaydi. Hattoki sen mingdan bir ilmini ololmagan ba'zi ulamolar ham o'ta darajada tavozeli, kamtar bo'lishgan. Bunga misol: Ato ibn Abu Raboh rohimahulloh deydi: «Bir yigit menga bir rivoyat aytadi, o‘zimni avval eshitmagandek tutib diqqat bilan uni eshitaman, holbuki bu rivoyatni men uning tug‘ilishidan oldin eshitgan bo‘laman». https://t.me/islom_aliy

Facade haqida birinchi marotaba o'qib chiqganimdan keyin 😎

Fozil aka ham o'zlarini bilim tajribalarini share qilishni boshlabtilar hayrli bo'lsin. https://t.me/samiyev_uz

Mandayam N ta pikr bor…

Databaselarni qurishda eng muhim componentlardan biri bu Storage yoki Memory Engine hisoblanadi )). Bazilar o'zi yozib chiqadi bazilar esa alohida qo'yadi. Bu narsa aynan ma'lumotlar bilan ishlash uchun maxsus soft. MongoDB da WiredTiger ishlatilgan 3.2 versiondan boshlab ))

Agar Paralell computing mavzularida izlanishlar qilinmaganda va piroritet pastligicha qolaverganida xozirgi biz o'ynaydigan 3D o'yinlarni va grafikani ham tassavur qilish qiyin edi ))). Suniy intelekt mavzularini gapirmasa ham bo'ladi )). Bu mavzuni o'zim uchun kashf qilgan kunim bayram bo'lgan edi. 3 kundan keyin esa bayram motamga aylangan mavzularni ko'rib 😅 Lekin yaxshi fundament bilan birin ketin o'qilsa eplasa bo'ladigan mavzular ))

Umuman olganda, parallel programming 2004-2005 yillardan boshlab amaliyotda keng qo'llanilishni boshlagan. Bunga sabab aynan o'sha yillarda CPU clock speed o'sishdan to'xtab, clock speed bo'yicha Moore's law buzilgan. Clock speed o'sishdan to'xtashiga sabab esa CPU power density juda yuqori bo'lgani va buyog'iga klassik Dennard scaling ish bermasligi bo'lgan. 2004-yilgacha performance engineeringda bir oltin qoida bo'lgan – dastur sekin ishlasa optimizatsiya qilmay shunchaki 2-3 yil kutib tur. Bu vaqtda yetarlicha kuchli komputerlar ishlab chiqiladi. Clock speed o'sishdan to'xtagani sabab bu usul endi ish bermaydigan bo'ldi. Endi yangi usullarga ehtiyoj tug'iladi. Ana shu vaqtda 80-yillardan beri faqat ilmiy maqolalarda va kichik tajribalarda eslab kelingan parallel programming hammaning e'tiboriga tushadi va eng yaxshi yechimlardan biri bo'lib chiqib, juda tez ommalashadi. Source: MIT OCW 6.172

Multiprogramming haqida yozilgan maqola. Eng qizig'i 1978 yil yozilgan. Yanayam qiziq tomoni esa ana o'sha payitda bunday texnalogiyalarni implement qilish xaqida multi taskling haqida izlanishlar avjida bo'lgani 😅. Mani yanayam qiziqtirgani o'sha payitlarda devicelar qanday bo'lgan ))) kb yoki mb storage )) CPU esa multi core bo'lmaganham bo'lsa kerak. Sience bizdan ancha oldinda ))

Software architect kim ? Software architect "architecture characteristics" (“-ilities”) ni sifatiga javob beradigan inson. Software architecture nima uchun muhim ? Loyiha sifati uchun albatta uning arxitekturasi muhim. Loyiha qurishdan oldin barcha business , texnik imkoniyatlarni va boshqa aspectlarni analiz qilish va shunga qarab ma'lum xususiyatlar(architecture characteristics) sifatini oshirish uchun ham arxitrektura muhim shu bilan birga bu bilan shug'ullanadigan alohida hodim(lar) kerak. Architecture vs Design Arxitektura qayerda boshlanadi dizayn qayerda tugaydi ? Arxitektura biror muammoga biznes va texnik tomonlarni xisobga olib arxitekturaviy xususiyatlar sifatini oshirish uchun umumiy tizimni chizmasini qurish. Dizayn esa aynan o'sha chizmalar asosida barcha narsani qurish. Arxitektor tizimda qanday patternlar va componentlar bo'lishini qanday domainlar bo'lishini aniqlab tuzib chiqadi.

Methodni yana update qildim )) Endi har yakshanba aniq o'rganadigan mavzularimni list qilib olaman o'zim uchun. Keyin o'sha mavzular doirasida o'qib chiqaman. Listni tuzayotganda foydalanadigan adabiyotlaringizgacha hal etib oling. Man dushanbadan boshladim. Yani bugundan )) Ertalapdan kichikroq mavzuni o'qiyman (Kechasi uyqu bo'lmagani uchun miyya qanchalik qabul qilishini bilmayman). Kechga esa yoki ertaga konspektlar qilib ko'raman )). Chorshanbadan esa full focus va energy bilan ertalabdan dars tayyorlash kerak 🥹 Bye ! Gamming 😢 Bye ! All time killers Agar darslar yaxshi ketsa gammingni yegishtirmayman 😎 Bo'lmasa hamma ortiqcha narsa chopiladi. Agar xabarlarga javob bermasam ayibga buyurmaysizlar ))

Code haqida qisqa izoh. 1. get va set keywordlar barcha tillarda ham mavjud emas. Shu sababdan bu birmuncha abstract qilib yozilgan koproq odamlarga tushunarli bo'lishi uchun )). Static methodlar haqida maqola yozganimda o'zim barchaga tushunarliroq syntax o'ylab topgan edim. 2. Undan tashqari falsafiy nuqtai nazardan encapsulationdagi asosiy focus encapsulable objectga nisbatan bo'lishi kerak bu degani host bo'lishi shart _host emas. Mani falsafam boyicha shunday. Endi mavzuga qaytamiz. Getter setterlar orqali siz field encapsulation qildingiz deylik. Shundan keyin birqancha savollarim bor )) 1. Siz yozgan classni boshqa threadga bervordingiz nima bo'ladi ? 2. Test yozganingizda aynan o'sha getter setterlari bor objectda biror mutation qilib yubordingiz nima bo'ladi ? 3. Siz hali biror narsani set qilmasdan get qildingiz )) Sizga null yoki undifined qaytardi keyinchi )) Yoki siz ham qayerdadur shuni tekshirasiz yoki return qilasiz lekin barbir tekshirasiz )) Hosh keyinchi ? 4. Sizni object anchagina kattalashyabti qanday kengaytirasi ? PS: Xozircha shu savollarga javoblar o'ylab turing ))

Code haqida qisqa izoh. 1. get va set keywordlar barcha tillarda ham mavjud emas. Shu sababdan bu birmuncha abstract qilib yozilgan koproq odamlarga tushunarli bo'lishi uchun )). Static methodlar haqida maqola yozganimda o'zim barchaga tushunarliroq syntax o'ylab topgan edim. 2. Undan tashqari falsafiy nuqtai nazardan encapsulationdagi asosiy focus encapsulable objectga nisbatan bo'lishi kerak bu degani host bo'lishi shart _host emas. Mani falsafam boyicha shunday. Endi mavzuga qaytamiz. Getter setterlar orqali siz field encapsulation qildingiz deylik. Shundan keyin birqancha savollarim bor )) Siz yozgan classni boshqa threadga bervordingiz nima bo'ladi ? Test yozganingizda aynan o'sha getter setterlari bor objectda biror mutation qilib yubordingiz nima bo'ladi ?

1. Bunaqa narsa aynan hayotga to'g'ri tadbiq qilinadigan bo'lsa juda yaxshi. Masalan talanti bor ammo imkonsiz yoshlar uchun yanayam katta imkoniyat. 2. O'quv markazdagilar ham faqat puli borlarga emas talantli yoki potensiali borlarga focus qaratishiga koproq imkoniyat bor. 3. Bu narsa IT ga aloqador fanlarni rivojlanishiga ham turtki bo'lish extimoli yuqori. Bizda computer sience bilan shug'ullanadigan insonlar juda ham kam. Bu degani olimlar ko'paysa texnalogiya rivojlanadi. 4. Ammo bunday qadamdan keyin keyingi qadamlarni ham ulash maqsadga muvofiq deb o'ylayman. Sababi oddiy 1mln dasturchi loyihasidan misol )). Bu loyihada maqsad son edi. Shu sabab sifat o'ldi. Sohada hamma yuqori darajaga ko'tarila olmaslik masalasiga manam qo'shilaman. Sababi raqobat oshgan sari hamma ham bunga turib bera olmaydi. Bazilar oddiy pozitsiyalarda qolib ketadi. Bazilar yuqori sifatli kadr bo'lib yetishadi. Kadrlar masalasida esa bizda xozir asosan katta qatlam oddiy ishchi. Chet elga oldin ham oddiy ishchi export qilinar edi xozir ham ayni o'sha model faqat Aytishniklar )). Davlat bu masalalarga qanday qarashi va qanday rejalar qilgani bir tomondan manga qiziq. Boshqa tomondan o'zim va atrofimdigilarga oldin shu narsalarni tushuntira olishimni o'zi katta natija )). 5. Nima bo'lsa ham o'zingiz ustingizda koproq ishlashingizni va biror infratuzulmaga bog'lanib qolmasligingizni tavsiya qilaman ))

Procedurial encapsulation )) PS: Qolgan trashlar haqida keyinroq ))

Procedurial encapsulation ))

class URL {
  private host: string ;
  public getHost:string() { return this.host; }
  public setHost(host: string): void { this.host = host; }
}