Engineering Notes

Shu paytgacha Javaning file(fayl)lar bilan ishlash usulini unchalik yoqtirmas edim. Yaqinda Pythonda yozilgan codebase ustida ishlashimga to'g'ri keldi. OOP paradigmda yozilgan, kod sifati ham ancha yaxshi.
Faqat file system bilan ishlash uchun hech qanday custom layer yozilmagan, Pythonda standard qanday bo'lsa shunday ishlatilgan.
Python filesystem bilan ko'proq functional styleda ishlagani uchun shu narsa kodning qolgan qismidan ajralib qolgan va ba'zi muammolarni keltirib chiqargan. Dasturning kattagina qismi file system bilan ishlashi sababli Pythonda filelar bilan object-oriented styleda ishlash imkonini beradigan "wrapper" yozishga qaror qildim.

Idealarni cheklamaslik uchun internetdan izlab ko'rishdan oldin biroz "brainstorm" qildim. Ikkita alohida-alohida ideani analiz qilib ko'rdim. Keyin ikkalasining yaxshi tomonlarini birlashtirishga harakat qilib ko'rdim. Boshida e'tibor bermagan ekanman, 1 soatlardan keyin qaytib kelib chizilgan designga qarasam Javaga ancha o'xshab qolibdi. Shular bir narsani bilsa kerak deb implement qilib ko'rdim. Yaxshi ishlayapti.

Javachilar uchun oldik ☕️

Yaqinda bir dasturchi bilan gaplashib qoldim. Aytishicha, yaqinda hamma narsa cloudga o'tib ketar ekan. Natijada DevOps, System Engineer va hokazolarga umuman ish qolmas ekan. Xo'sh, o'sha cloudlarni kim qurib, maintain qiladi desam javob bera olmadi. Tushuntirishga harakat qildim, menimcha foydasi bo'lmadi. Sohani chuqurroq o'rganishga yana bir motivatsiya.

Cheers

Virtual memory va umuman, operating system levelda memory management men o'ylagandan ko'ra ancha qiziq ekan.

Rasm manbaasi: Modern Operating Systems, 4th edition

Model K, birinchi half-adder. Elektron kalkulyator va komputerlar g'oyasining eng birinchi ko'rinishi. Boolean algebra va electromagnetism orasidagi ko'prik. Arifmetik amallarni bajarish uchun elektr tokidan foydalanish mumkinligini ko'rsatgan birinchi qurilma.

Webpage server-side render bo'layapti. O'zi shundoq ham serverda resurs yetmasligini bilib turib yana ortiqcha load qo'shish. Juda qiziq tanlov.

Xalq dengizdir, xalq to‘lqindir, xalq kuchdir,
Xalq botnetdir, xalq DDoSdir...

P.S. my.uzbmb.uz sog' bo'lasila✋

Jahongir akaning mana bu postini o'qib bir holat esimga tushdi. Qisqasi, eskiroq bir servisimizning funksionalligini o'zgartirmagan holda qayta yozib chiqishimiz kerak edi. Yaxshiki, bu servis uchun anchagina testlar yozilgan ekan. Codebaseni boshqa tilga o'tkazmayotganimiz uchun servis funksionalligini tekshirish osonroq bo'lishi kerak: eski servisdagi testlar refactoringdan keyin ham yaxshi o'tsa, demak servis to'g'ri ishlayapti.

Aniqrog'i, boshida shunday o'ylagandik. Lekin keyin savol tug'ildi: aslida funksionallik o'zgarib, lekin testlardan baribir o'tsachi? Ya'ni bizdagi testcaselar kichkina o'zgarishni ham seza oladigan darajada aniqmi? Masalan, bir koddagi if a < b joyi refactoringda if a <= b ga o'zgarib ketsa testlarimiz bu o'zgarish sabab fail bo'ladimi yoki o'tkazib yuboradimi?

Odatda, dasturchilar kodni test qilishadi. Lekin biz oldin testlarning o'zini test qilishimiz kerak edi. Biroz izlanganimizdan keyin bir jamoadoshimiz mutation test haqida gapirib qoldi (shunday test turi borligini o'sha vaqt bildim). Mutation test bu kodda kichkina o'zgarish (mutation)lar qilib, yozilgan testcaselardan qayta-qayta o'tkazish. Bundan maqsad kodni emas, testcaselarning o'zini tekshirish. Agar testlar yaxshi yozilgan bo'lsa, kod funksionalligi ozgina o'zgarganda ham qaysidir testcase fail bo'lishi kerak. O'zgartirilgan (mutant) kod hamma testlardan o'ta olsa mutation test fail bo'ladi. Dasturchilar natijani analiz qilib, testcaselarni o'zgartirishi, yangi testcase yozishi yoki shunchaki hech narsa qilmasligi mumkin.

Oldik☕️

O’quv kursi tanlayabganlar uchun:

Nomi wow bo’lgan o’quv markazni emas, u yerda kim dars berishiga va qanday ishlarni amalga oshirganiga qarab ta’lim markazi tanlashni tavsiya qilaman!

Siz uchun checklist berib o’tmoqchiman:
- Dars beryabgan insonni tajribasi va ishlagan loyihalariga qiziqing, qanday muammolarga yechim topgani va bu dasturlarini qancha odam ishlatyabdi?
- 100% mentorlik qilmasligiga e’tibor qarating
- Kurs rejasida, nimalar o’qitilishini aniq qilib oling.
- Kursdagi loyihalar faqat landing page, kalkulyator va shunga o’xshagan loyihalar bo’lsa, u yerda o’qimaslikni tavsiya qilaman.

O’quv markaz toping, mayli u yerda o’qing. Ustoz toping va u sizga har tomonlama yo’l-yo’riq ko’rsata olsin.

Baliq tutishni o’rgatadigan ustoz va joy toping, tayyor tutilgan baliqni yeyishni o’rgatadigan joyni emas. Qanday o’rganish kerakligini o’rgatadigan joyni toping!

Mana bu yerda to'g'ri javobni topish uchun Pythondagi ba'zi xususiyatlarni tushuna olish talab qilinadi.

1. Python o'zgaruvchi nomlarini qiymatlarga bog'lash uchun reference ishlatadi. Masalan, a = 4 bo'lsa Python 4 qiymatli obyekt ochib, "a" variableni shu qiymatga bog'laydi.

2. Bir o'zgaruvchidan ikkinchisiga qiymat olinganida (b = a) Python yangi obyekt yaratmaydi, balki yangi o'zgaruvchini ham eskisining qiymatiga bog'lab qo'yadi.

3. Pythonda listlar mutable, ya'ni uning qiymatini dastur davomida o'zgartirish mumkin.

4. del keywordi obyektni xotiradan o'chirmaydi, faqatgina o'zgaruvchidan obyektga bo'lgan referenceni o'chiradi. Obyektni xotiradan o'chirish faqatgina garbage collectorning ishi.

Endi kodni bir boshidan ko'rib chiqamiz.

a = [0, 1, 2]
b = a
a list ochildi, keyin b a dan qiymat oldi. Demak endi a va b bitta listga qarab turibdi.

b.append(3)
print(a)
b o'zgaruvchi qarab turgan listga yangi element qo'shildi. Lekin a va b bitta listga qarab turgani uchun ikkalasi ham endi [0, 1, 2, 3] bo'ldi. Demak birinchi natija [0, 1, 2, 3].

del a
print(b)
Tepada aytilganidek, del bu yerda listni o'chirmayapti, balki shunchaki a o'zgaruvchini listdan "uzib" qo'yayapti. Demak b o'zgaruvchiga zarar yetmagan va ikkinchi natja ham [0, 1, 2, 3].

"In theory, theory and practice are the same; in practice, they are not."

© Yogi Berra

C tilida yozilgan kod assemblyga compile qilinganida assembly kodda qiziq redundency holatlari sodir bo'ladi. Masalan, branching (if statement yoki loop) sabab kelib chiqadigan processor pipelining bilan bog'liq muammolar. Yana bir misol redundant instruction ketma-ketligi (tajribamda ko'rganim, tez-tez bir C statementdagi oxirgi 1-2 ta instruction keyingi statementning boshidagi 1-2 ta instruction bilan teskari (bir-birini bekor qiladigan) bo'lib chiqadi). Xullas, oddiyroq C compilerdan olingan assembly kodni optimize qilib yaxshiniga qo'shimcha performance olsa bo'ladi.

Tepada aytilgan muammolarning ba'zilarini yechish uchun ishlab chiqilgan idealardan xabarim bor (masalan branching bilan bog'liq oddiyroq holatlarni "branchless programming" texnikasi bilan hal qilish mumkin). Meni qiziqtirgani, compilationdan keyin shunga o'xshash ko'p uchraydigan holatlarni alohida optimize qilish uchun hozirda ishlatilayotgan qanday murakkab toollar bor?

Mabodo meni interview qiladigan biror engineer ham OOPni shunday o'rgangan bo'lsa o'sha interviewdan aniq fail bo'laman. Notes LinkedIndan olindi.