Declarative vs Imperative Programming

Ushbu 2 paradigm paradigmlar asosi xisoblanadi desam mubolaga' bo'lmaydi chunki Paradigmlar aynan shu 2ta turga ajraladi. Misol uchun OOP, FP bu Declarative xisoblansa, Procedural va OOP (haqiqiy OOP emas) Imperative xisoblanadi. Hop keling ikkisini farqini tushinib olsak.

Imperative Programming

Imperative Programmin is about "HOW a program works". Aniqroq tushunchada aytadigan bo'lsa siz sochizni oldirayabsiz. Sartaroshga qarab:

"Xullas oka, sochni orqasini ozgina, ikki yonini kaltaro va ustini uch-uchuidan olib qo'ying." deyishingiz bu har bir qadamni qanday bajarishni aytishga to'g'ri keladi va sartarosh ham xuddi shunday oladi. Shu narsa Imperative Programming deyiladi. Pythonda example keltiradigan bo'lsak

total = 0
nums = [1, 2, 3, 4, 5]
for num in nums:
total += num

Ushbu kod aynan imperative xisoblanadi chunki har bir stepni siz tasvirlab berayabsiz qanday bo'lishini.

Declarative Programming

Declarative Programmin is about "WHAT a program does". Yana o'sha sartarosh oldidasiz, ammo bu safar siz unga qarab:

"Xullas oka, sochimni mana bunga o'xshatib qo'ying." deyishingiz bu qanday qilishini farqi yo'q ammo shunday natija bersa bo'ldi deganday gap.

nums = [1, 2, 3, 4, 5]
total = sum(nums)

Ushbu kod aynan declarativega to'g'ri keladi chunki siz steplarni keltirmayabsiz qisqacha qanday natija xohlashizni aytayabsiz xolos.

It's all about Abstraction

Barchasi borib abstractionga taqaladi chunki bizga uni QANDAY ishlashi emas balkim NIMA qilishi ya'ni ishlashi muhim deyishday gap.

Post idea chopildi, rozi bo'lasiz )

@otabekswe

Database Transaction

The Problem
Anna databasega id=1 teng kitob chiqarilgan sanasi (release_year)ni olish uchun query yozdi va unga 2004 javobi qaytdi. Xuddi shu vaqt Sam shu kitobni chiqarilgan sanasini (2012) va nashrini (4-nashr) o'zgartirish uchun query yozdi. Anna biroz vaqtdan keyin yana shu "release_year"ini oldi va natija bu safar o'zgarib qoldi. Biroz vaqt o'tib esa Sam adashganini sezib ROLLBACK qilib yubordi.

The Solution
Transaction ma'lumotlarni "consistency"si bilan bog'liq muammolarni oldini olish uslubi xisoblanadi. U ACID tamoyili bo'yicha ishlashi kerak va transaction konseptsiyasidan asosiy maqsad transaction tugagunicha butun bir jarayonni izolyatsiyalash xisoblanadi. Xo'sha ACID nima?

ACID
ACID bu Atomicity, Consistency, Isolation va Durability.

Atomicity
Qachonki transaction (read/write) sodir bo'lsa, barcha operatsiyalar bir vaqtning o'zida sodir bo'lishi kerak yoki umuman bo'lmasligi kerak. Agar transaction to'xtatilsa yoki xatolik yuz bersa, databasega ta'sir qilmasligi kerak va butun jarayon oldingi xolatiga qaytishi kerak. Xuddi shunday, agar transaction amalga muvaffaqiyatli oshirilsa, database holati o'zgarishlarni qabul qilishi kerak. Qisqacha aytganda yoki hammasi muvaffaqiyatli kechadi yoki hech biri bajarilmaydi.

Consistency
Transaction faqat databaseni bir holatdan ikkinchisi olib o'tishni taminlaydi ya'ni databasega yoziladigan har qanday ma'lumotlar barcha belgilangan qoidalar (constraints, cascades, triggers, va boshqa)ga muvofiq ishlashi kerak. Qisqachasiga, noqonuniy ma'lumotlardan qochish imkoniyatini beradi.

Isolation
Har bir transaction operatsiyalari izolyatsiyalangan bo'lishi kerak ya'ni race condition keltirib chiqarishi kerak emas degani. Database transactionlar ketma-ket bajarilishini ta'minlash uchun row(qator)larga lock (qulf) qo'yib chiqadi. Qisqachasiga, Concurrency controlni aynan isolation bajaradi.

Durability
Transaction amalga oshirilgandan so'ng, tizim ishdan chiqgan taqdirda ham ma'lumotlar saqlanib qolishi kerak.

Real Life Example

Atomicity
Do'stingiz xisobiga 100$ o'tkazayabsiz. Jarayonlar esa: avval sizni xisobingiz tekshiriladi so'ngra xisobingizdagi summadan 100$ ayriladi va do'stingiz xisobi tekshirilib unga 100$ ni qo'shib qo'yadi. Oddiy logika )

Consistency
Sizning xisobingiz manfiyga aylanmasligi va unda yetarli mablag' bo'lishi bu qoida sifatida beriladi. Agar qoida buzilsa kompaniya minusga ishlaydi. Bunday qoidalar juda ko'p bo'lishi mumkin va men qisqacha keltirdim.

Isolation
Operatsiyalar to muavaffaqiyatli bajarilmagunigacha sizga va do'stingizga hech qanday o'zgarishlar ko'rinmasligi shart. Barcha jarayonlar isolation bo'lgan bo'lishi kerak.

Durability
O'tkazma muvaffaqiyatli kechdi endi ma'lumotlar saqlanishi va o'chib ketmasligi shart.

Transactiondan maqsad va muamolarni to'g'ri yoritib berdim deb umid qilaman.

@otabekswe

SQL Trigger

SQL Trigger - insert, update, (truncate) yoki delete operatsiyalaridan sodir bo'lgandan oldin yoki keyin avtomatik ishga tushuvchi funksiya xisoblanadi. Ular tablega bog'liq funksiya xisoblangani uchun, avval trigger function yaratasiz va uni biror tablega bog'lab qo'yasiz.

Types
PostgreSQL, MySQL asosan 2 turdagi triggerlarni taqdim qiladi, row-level va statement-level trigger. Ikkisini bir-biridan farqi necha marta va qaysi vaqtda ishga tushishida. Oddiyroq misol keltiradigan bo'lsak, 100 ta ma'lumot insert qilayabsiz demak row-level 100 marta ishlasa statement-level 1 marotaba ishlaydi.

Hozirda ba'zi ORMlar ham event sodir bo'lishidan oldin yoki keyin qandaydir ishlar qilish imkoniyatini berishini bilishingiz mumkin misol uchun SQLAlchemy va Django ORM. Django signals bu triggerni ORM level implementatsiyasi xisoblanadi. Ishlashi database-level triggerga o'xshaydi va siz pre_init, post_init, pre_save, post_save kabi signal turlari bilan o'zingiz hohlagan vaqtda biror logikani amalga oshirishingiz mumkin.

Problems with triggers
Triggerni kamchiliklari yo'q ammo dasturchilarda bor chunki hamma narsani ham triggerga berish xato. Triggerdan faqat kerak bo'lgan xolatdagina foydalanishni tavsiya qilaman. Ba'zan noto'g'ri yozilgan trigger juda ko'p muammolarga olib kelishi mumkin chunki ular avtomatik ishga tushgani uchun sizga ko'rinmaydi. Ba'zan esa ko'plab foyda olib kelishi mumkin ya'ni ishingizni, vaqtingizni tejashi mumkin.

@otabekswe

SQL View

Complex querylarni qayta-qayta yozishdan yoki copy/paste qilishdan charchagan data engineerlar SQLga shikoyat yozibdi. SQLni yaratgan jamoa esa bu muammoga yechim izlashga kirishadi. Yechim sifatida esa bizga View terminalogiyasini taqdim qiladi. (Ertaknamo boshlanish 😉)

SQL View - bu virtual table bo'lib u o'zida ma'lumot saqlamaydi balkim bir yoki bir nechta tablelarni olib keladi (albatta databasedan). View orqali complex (qiyin) querylarni bo'laklarga bo'lish orqali soddalashtirish va ularni more managable qilish mumkin. Ularga access limit ham berish mumkin, zo'r-a?

Types of Views
SQLda 2 turdagi viewlar mavjuda va ular: Regular views va materialized views xisoblanadi.

Regular views - bu oddiy view bo'lib, bir nechta tablelardan ma'lumot olib kela oladi ammo shu bilan birga JOIN, SUBQUERY va boshqa turdagi statementlar bilan ishlatiladi.

Materialized views - biror viewdan olib kelingan ma'lumotlarni physical copysi xisoblanib, ular alohida tableda saqlanadi.

Real life examples
Tabledan qanday ma'lumotlarni select qilsangiz viewdan ham shunday qilasiz ammo farqi view sizga uzundan-uzun va complex querylarni qayta yozib o'tirmasligingiz uchun juda katta yordam beradi. Misol uchun E-commerce website yasasangiz, customerlarga buyurtma va yetkazib berish uchun alohida-alohida saqlangan ma'lumotlarni birlashtirib single view orqali chiqarib berishingiz mumkin. Bunda misollar juda ko'p.

Conclusion
Gapni indallosi sifatida, view xuddi o'zgaruvchidek gap. Siz unga queryni saqlaysiz va har safar queryni emas balkim viewni chaqirasiz, u esa sizga o'sha queryni beradi.
✅
SELECT id, name, order_no FROM customer_view;

❌
SELECT id, name, order_no FROM (SELECT customer.id, customer.name, orders.number AS order_no FROM customer JOIN orders ON customer.order_id = orders.id) AS customer_view;

@otabekswe

Hech qachon Senior bo'la olmaydiganlar

Har bir soxani eng zo'r mutaxasislari bo'lganidek eng yomonlari ham bo'ladi. Bunday insonlarni ajratib olish umumman qiyin emas shunchaki ularni ba'zi xislatlari ularni hech qachon rivojlanmasligini ko'rsatib beradi. Keling ularni birma-bir sanab nima uchun bunday xulosaga kelganimni aytib beraman.

1. Google qilishni bilmaydiganlar - Internetda hozirda oddiy va suyqasi chiqib ketgan savollarga ming xil javob olishingiz mumkin. Agar siz "JavaScript nima?" "For loop qanday ishlaydi?" kabi savollarni odamlardan so'rayotgan bo'lsangiz tabriklayman, siz shu insonlar qatoriga kirdingiz.

2. Unutuvchilar - Kechagi xatosi, o'rgangan mavzusi yoki nima bo'lsa ham uni tez unutsa demak bu toyifa ham rivojlanmaydi. "Qonunlar qon bilan yozilgan" degan naql bor. Ya'ni ba'zi qonunlarni bilmasangiz yoki unutsangiz qon to'kishingizga to'g'ri keladi. Unutmaslik uchun esa ko'proq yaxshiroq izlanib amaliyot qilish juda zarur.

3. Ma'suliyatsizlar - Har bir odamni jamoada o'z ma'suliyati va majburiyatlari bo'ladi. Ulardan qochish, yaqinlashmaslik yoki yechim qidirmaslik tajribadan quruq qolish bilan barobar. Bir kunmas-bir kun agar sizni hech kim jamoaga qo'shishni xohlamasa xafa bo'lmang, chunki siz ma'suliyatsizlik qilasiz va hech kim sizga nimadirni ishonib topshirgisi kelmaydi.

4. Taqqoslovchilar - Tez-tez language, framework yoki toolarni bir-biri bilan solishtirib yomonlovchilarni eshitib qolamiz. Bu ham shunday dasturchilardan dalolat. Computer Science olamida qurollar juda ko'p ammo eng qulayidan foydalanish dasturchiga borib taqaladi. Nima uchun Google C++, Java ni ko'proq ishlatishini sababi ular boshqalariga qaraganda ulardagi muammoga ko'proq, efficientroq yechim deb topilgani uchun. Ko'p ish yoki kam ish deb ajratish ham yomon, btw.

5. General bilmlardan qochuvchilar - Faqat dasturlash tili, frameworkga bog'lanib qoladigan va umumiy bilimlarni o'rganmaydiganlar ham shu insonlar safida bo'ladi. Umumiy bilimlar aslida bu narsalar nima, qachon va qayerda to'g'ri ishlatish mumkinligini sizga o'rgatadi. Muammoga turli-xil prespectivedan qarash imkonini beradi. "Ularni qayerdan o'rganaman?" deysizmi, albatta kitoblardan. Demak xulosa kitob o'qimaydiganlar ham pro bo'la olmaydi.

Bu postni ko'pchilik xatto o'qimaydi ham, o'qisa ham bir kunmas-bir kun esdan chiqaradi. Ammo maqsadim 2ta odam o'qisa ham ularga katta ta'sir qilib zo'r rivojlanishsa men roziman.

P.S: Fikrlar o'ta subyektiv va ba'zilari (balkim barchasi) noto'g'ri bo'lishi mumkin. Let me know if am wrong!

@otabekswe

How Database Stores Data

Database internally ma'lumotlarni Heap file ichiga saqlab boradi. Har bir row esa item (tuple) ko'rinishida bo'ladi. Heap file esa bir nechta pagelardan iborat bo'ladi va har bir page qanchadir miqdordagi (rowlar) ma'lumotlar saqlanadi. Ya'ni bizda bitta table bor degani bu bizda o'sha tabledagi ma'lumotlarni saqlash uchun heap file bor degani. Heap file ichida esa bir nechta page(block)lar ham bo'ladi.

Endi tasavvur qiling, kimda age > 30 bo'lsa barcha ma'lumotlarni taqdim qilishini so'radik. PostgreSQL kimni yoshi nechidaligini bilmaydi, shuning uchun avval u barcha rowlarni RAMga olib keladi va list shakliga olib o'tadi (majoziy ma'noda list deyildi). Endi shu listdan har bir rowni birma-bir kirib tekshiradi va kimda age > 30 bo'lsa o'shalarni olib qaytaradi. Hop ammo bu yerda katta minus bor. Agar tasavvur qiling bizda rowlar soni millionlab bo'lsachi, ma'lumotlarni RAMga olib kelish juda qimmatga tushadi.

Xulosa: Bu juda qisqacha ta'rif bo'ldi ammo ko'proq o'rganish uchun esa ushbu manbadan ko'rib chiqishingiz mumkin:
- storage page layout

@otabekswe

How database indexing works

Tasavvur qiling yonimda 1000 betli kitob, Sarah va Lisa turibdi. Men Sarahga qarab "Hey, men seni seva... e uzur, menga Hamlet asarini topib ber shu kitobdan" dedim. U varoq titkilashga o'tdi. Ho'sh u asarni topganicha men zerikib ketib u bilan bo'lgan aloqani uzvordim. Chunki juda sekin qidirardi.

Endi esa Lisaga qarab xuddi shunday murojaat qildim. Lisa aqlli edi shuning uchun u darrov mundarija (book index) ni ochdiyu Hamlet asarini nechanchi pageda joylashganini topib menga o'sha pageni darrov ochib ko'rsatdi. Men uni yana ham yaxshi ko'ra boshladim.

Bu hikoyadan keyin siz "haa, database indexing shunday ishlar ekanda" deyayotgan bo'lsangiz shoshilmang, qisman ha ammo to'laqonlik unday emas. Keling internally nimalar bo'lishi haqida to'xtalib o'tamiz.

What is an Index?

Well, o'tgan maqaolada database barcha ma'lumot(page)larni RAMga olib o'tib keyin birma-bir ko'rib chiqishi haqida gaplashgandik va agar bizda millionlab rowlar bo'lsa bu bizga qimmatga tushishini tushungandik. Agar biz barcha pagelarni emas balkim aniq bir pageni olib o'tsakchi? Aynan shu ish indexing deyiladi. Bilamizki pagelarda qanchadir miqdorda cheklangan rowlar bo'ladi va biz bir necha pagelarni RAMga yuklab har bir pageni scan qilishimiz emas, shunchaki bitta pageni olamiz va undagi rowlarni qarab chiqish orqali operatsiyalar sonini sezilari tushirishimiz mumkin bo'ladi, voila 🤲 (Khabiyni qo'li)

Cost of Indexing

Indexing operatsiyalar sonini tushuradi va boshqa tomonnikini ko'taradi🥲. Misol uchun CRUD operatsiyalaridan Read qilish tezlashgani bilan CUD (Create, Update, Delete) uchun qo'shimcha ishlar paydo bo'ladi. Oldin faqat tablega ma'lumot yozsangiz endi indexga ham yozasiz va qancha ko'p index bo'lsa shuncha ko'p operatsiya bo'ladi.

Post foydali bo'lgan bo'lsa uni share qilmang, bu juda xavli. Hamma senior bo'lib ketmasin deymanda 😉

@otabekswe

#interview

Intel kompaniyasi bilan bo’lgan interviewdan rejact oldim. Ammo bu ham tajriba. Ushbu postni bir kun reply qilish nasib qilsin deya shu yerga joylab qo’yayabman.

Bollar biz yutamiz!

Ushbu ko'rib turgan funksiyalaringiz siz pythonda sevib ishlatadigan logical operatorlar.

Ularni implement qilish uchun print ichidagi ifodalarni run qilib ko'ring (stringsiz) va keyin men tuzgan funksiyalar bilan run qilib ko'ring.

Qarabsizki bir xil natija olasiz. Savol endi ham math kerak emasmi?

For more

@otabekswe

API Throttling

Hop, menimcha ushbu postni o'qib turgan barcha insonlar API nimaligi haqida bilishadi. API Throttling - API ga yuboriladigan requestlar sonini qanchadir vaqt oralig'i uchun cheklash. Tasavvur qiling telegramda xabar yozib yuborish uchun ko'k "samalyotcha"ni bosdingiz ho'sh bu yerda nimalar sodir bo'ldi?

Ushbu jarayonda o'sha "samalyotcha" event sodir bo'lgani haqida xabar topadi va API ga request yuboradi (albatta xabaringiz o'sha request ichida ketadi). API esa telegram web serveri bilan bog'lanadi va ushbu buttonni vazifasi nima uchun bo'lsa o'sha vazifani bajarishga kirishadi (ya'ni server sizni xabaringizni oladi va boshqa user, bot yoki e.t.c. ga jo'natadi).

Throttling faqat Backendga yoki APIga tegishli yechim emas balkim umumiy callable larga tegishli. Misol uchun Frontend da ham throttling qilish mumkin ya'ni siz dasturlash tiliga "hey mana bu funksiyani har minutda faqat 5 marta chaqrishga ruxsat ber" deysiz tamom (kod yozish bilan aytasizda).

Ko'p xolatlarda resurs tejashlik maqsadida ko'proq ishlatiladi chunki keladigan requestlarni barchasiga server javob berishi orqali ko'p resurs sarflanadi (downtime). Misol uchun Leetcode subnoscription sotib olmasangiz code run qilishingiz uchun rate limit ya'ni cheklov o'rnatib qo'yadi. Bu ham aynan throttle qilish orqali yuzaga keladi.

Ko'proq bu yerdan...

@otabekswe

Application Layer (part-1)

Backendga Sayohat loyihasi davom etadi. Endigi navbat OSI modelini eng yuqori qavati "application layer"ni kashf qilishga.

Ba'zi joylarda adashgan yoki xato qilgan bo'lsa izohlarda aytib o'ting.

Post foydali bo'lgan bo'lsa bizni duo qilib turing )

@otabekswe

Nima uchun FAANGda DS Algo bo'yicha interview qilishadi?

FAANG kompaniyalariga shu paytgacha 5ta interview qilishga ulgurdim va 4tasidan rejact bittasi bilan davom etayabmiz (hozircha sir 😉). Intel, Amazon, Nokia va Bank of New York Mellon kompaniyalarida ham bir xil DS Algo interviewlari bo'ldi. Xo'sh interview oxirida 2ta ajoyib insonlar bilan connection qilib oldim va savollar berdim. Bulardan biri bu "Nima uchun FAANGda DS Algo bo'yicha interview qilishadi?" Javoblarni umumiy va soddalashtirib quydigachi xulosalarga keldim:

1. Problem analysis - Dasturchilar muammolarni yechuvchi insonlar bo'lgani uchun ham ulardan kuchli "muammo tahlil qilish" ko'nikmalari talab qilinadi. Bu orqali esa dasturchi qachon, qayerda va qanday qilib muammoga to'g'ri yondashuv qila olishini kuzatish mumkin.

2. Language proficiency - Dasturchilarda til borasidagi bilimlari bo'yicha savollar berib o'tirgandan ko'ra, ularni amaliyotda qanchalik to'g'ri va moxirlik bilan ishlata olishini tekshirish osonroq ekan. Tasavvur qiling siz nazariyda zo'r bilimga egasiz ammo amaliyot qilib ko'rmagansiz, bu yomon va ushbu muammoni oldini olish uchun sizdan ko'proq amaliy vazifalar berish orqali aniqlash ancha vaqtdan yutish imkonini beradi.

3. Soft skills - Jamoaga sizni kiritishdan oldin sizni qanday soft skillga egaligingizni tekshirish uchun ham bu interviewlar juda zo'r, chunki muammo aniq, yechim uchun sizda ko'plab aniq va sodda fikrlar so'raladi. Siz qanchalik yaxshi tushuntirish qobilyatiga ega bo'lsangiz, qanchalik muammoni yechimini sherigingiz (interviewer) bilan tahlil qilsangiz shuncha yaxshi soft skillga egasiz degani )

... va boshqa sabablar ham bor, ammo eng asosiylar menimcha shular.

Latofat Bobojonova: Internship qilish uchun tajriba emas yaxshi project(lar) va kuchli bilm bo’lsa yetadi. Sinab ko’rilgan uslub :)

P.S: Ushbu postni o'z tajriba va fikrlarim asosida yozayabman

@otabekswe

#TechTalks

Google kompaniyasida 2 marotaba ketma-ket internship (amaliyot) qilgan o'zbek qizi, va loyihamizning birinchi mexmoni Latofat Bobojonova bilan o'zgacha suxbat.

Ushbu suhbat ochiq, samimiy va boshqalaridan qiziq bo'ladi.

Vaqt: 18:00 (Toshkent vaqti bilan)
Sana: 22-Oktyabr
Mavzu: Life at Google

@otabekswe

Speaker: Latofat Bobojonova
Topic: Life at Google
Duration: 55 minutes

Database normalization

Database implement qilishdan oldin juda puxta va uzoq fikr qilishni tavsiya qilaman. Chunki har bir o'zgartirish yoki yangi qo'shimchalar kiritish sizga qimmatga tushishi, ba'zan esa katta muammolar ham keltirishi mumkin. Xuddi shunday muammolarni keltirib chiquvchi omillardan biri bu ne-normal database xisoblanadi.

Database normalization - ma'lumotlarni tartibli va izchil tarzda orginize qilish uchun ma'lumotlar bazasini dizaynlash tamoyili. Keling misollar bilan ko'rib chiqamiz.


1NF - First Normal Form

Birinchi normal formada ma'lumotlar atomic va unique bo'lishi kerak bo'ladi va uzunroq qilganda ushbu prinsiplarga amal qilishi kerak:
- hech bir cell bittadan ko'p ma'lumot saqlamasligi kerak (atomicity)
- identifikatsiya qilish uchun primary key bo'lishi kerak
- duplicate row yoki column bo'lmasligi kerak
...

Tasavvur qiling, foydalanuvchini "Address"ini saqlamoqchisiz. Siz nazarda tutgan "Address" = "Toshkent shahar, Mirobod tumani, Amir Temur ko'chasi, 56 uy" ammo yuqorida aytilganidek atomicity bo'yicha bunday ma'lumot saqlash yaxshi emas. Siz buning o'rniga manzillarni saqlash uchun alohida table yaratasiz va saqlangan ma'lumotni user tabledagi user_id ga foreign key sifatda aloqasini ta'minlaysiz, tamam )


2NF - Second Normal Form

Birinchi normal forma asosan uniqueness va atomicity ga e'tibor qaratsa, Ikkinchi normal forma redundancy and data dependency ni ta'minlashga ximzt qiladi:
- 1NF ni saqlab qolgan holatda ishlashi kerak
- Barcha non-key attributelar faqat primary-keyga dependen bo'lishi kerak.
...

Tasavvur qiling, kutubxona uchun database qildingiz. Sizga keladigan ma'lumotlar asosan kitoblar va avtorlar haqida bo'ladi. Ya'ni bitta avtor ko'p kitob yozishi yoki bitta kitob ko'p avtorlar tomonidan yozilgan bo'lishi mumkin. 2NF da huddi shu muammoni 1NF dan kelib chiqib hal qilasiz. Ya'ni books va authors degan tablelar yaratasiz. har bir kitob uchun book_id bo'lsa, avtor uchun author_id bo'ladi. Bu degani ManyToMany relationshipni endi juda osonroq yo'l bilan yecha olasiz degani. book tableda avtor haqida ma'lumotlarni author tablega, author tableda book haqida ma'lumotlarni olish uchun book tablega foreign key qilasiz holos, tamam.

Post juda cho'zilib ketmasligi uchun qolganlarini o'zingizga sovg'a qilaman, oling va meni eslab yuring (so'kinmasdan)🎁.

@otabekswe

Oltinga teng loyihalar

Ilm olishni hamma eplaydi. Ammo olingan ilm orqali muammolar yechishni hamma ham eplay olmaydi.

Loyiha qilish menga kompaniya bera olmaydigan tajribalarni bergan. Ayniqsa yangi til va texnologiyani tez o'rganib ketishimga sababchi bo'lgan.

Misol uchun:

gylo - Ushbu loyiha menga Cloudflare bilan interviewni olib bergan loyiha xisoblanadi

Menda bunday qiziq loyihalar ko'p afsuski ular private, rasmiyatchilikda aylanay 😉

Tez orada ba'zilarini public qilish niyatidaman. Ammo hozircha dsalgo.uz ustida ishlayabman )

@otabekswe

S.O.L.I.D

Agar umringizda OO code yozib ko'rgan bo'lsangiz demak siz albatta ushbu paradigm haqida eshitgansiz. Balkim tushunchalar unchalik ham zo'r bo'lmagandir ammo keling bugun shu haqida gaplashamiz (kamchiliklarini esa kelasi epizodda yozaman).

Single Responsibilaty

Har bir class faqat bitta ma'suliyatli ishni bajarishi kerak!

Open degan class yaratdingiz, unga nimani ochishni qizig'i yo'q DB connection och desangiz uni ham qilaveradi, fileni "w" modeda och desangiz uni ham qilaveradi umumman farqi yo'q. Ammo bu noto'g'ri yechim chunki bitta classni vazifalari qancha ko'paysa shuncha ko'p buggy bo'lish ehtimoli ham ko'payadi. Uning o'rniga esa OpenDBConnection, OpenFile va OpenFolder degan classlar yaratish tavsiya qilinadi.

Open-Closed

Classlar kengayish uchun ochiq, ammo modifikatsiya (o'zgarish) uchun yopiq bo'lishlari kerak

Misol uchun OpenFolder classini olaylik. Shu classga faylni ham open qilish imkoniyatini berish mumkin ammo, classdagi imkoniyatlarni o'chirmagan yoki o'zgartirmagan xolda. Misol uchun. O'sha folder ichidagi fayllarni ochish uchun alohida method (open_file(filename: str, mode: str)) yozib chiqishingiz va simplicity maqsadida OpenFile classidan foydalanishingiz mumkin. Bu orqali esa qo'shimcha logika yozmaysiz shunchaki tepada aytilganidek yagona maqsadli klasslardan birini ishlatgan bo'lasiz :)

Liskov Substitution

Agar B class A classidan inheritance olgan bo'lsa, B class objecti A class objectini o'rnini bosa olishi kerak hech qanday o'zgarishlarsiz.

Ho'p nimalar bo'layabdi deyishga shoshilmang, qisqacha aytganda Kofechini o'g'li ham kofe tayyorlashni bilishi kerak. Agar "hey dadang ishga kelmabdi menga kofe qilib ber" deyishsa "mana suv iching kofe qilishni bilmayman" demasdan kofe qilib berishi kerak o'sha o'g'il degan ma'noni bildiradi. Ya'ni child class objecti, parent class objecti qila olgan ishlarni qila olishi kerak demoqchi. Menimcha bunga qandaydir chuqur misol keltirish shart emas deb o'ylayman, shu yetar )

Interface Segregation

Mijozlarga kerakmas bo'lgan narsalarni, ular ishlatishiga majburlamaslik kerak

Misol uchun OpenFile classiga databasega ulanish kerak emas. Va uni bunga majbur qilishga doir ishlarni uni ichida bajarish shunchaki useless. Ya'ni class faqat o'z vazifasiga tegishli ishlarni bajarishi kerak. Yana ham aniqroq aytsak static methodlar ham eval degani aylanay 😉

Dependency Inversion

High-level modullar yoki classlar low-level modul yoki classlarga bog'liq bo'lmasligi kerak. Buning o'rniga ular abstractionga bog'liq bo'lishi kerak

High-level class: ishni bajaruvchi.
Low-level class: ishni bajaruvchi qurol
Abstraction: Shu ikkisini bog'lovchi o'rtakash (connector)

Misol uchun Televizorni olaylik. Televizorni pulti o'zida yoki ichki mehanizmga bog'lanmasligi kerak. Agar shunday bo'lsa televizordagi o'sha qism buzilsa ham usta chaqirasiz, boshqa qism buzilsa ham usta chaqirasiz. Uning o'rniga esa pultni alohida masaofaviy boshqaruvga o'tkazishingiz mumkin bo'ladi. Pultni batareyasi o'chsa televizorni emas pultni ochasiz. Pult buzilsa televizorni emas pultni tuzatasiz . Xullas abstraction bu yerda ikkisini bog'lovchi tizmda aylanay )

Yuqoridagi tushunchalar to'liq yoritilmagan va ushbu yo'llar bilan yoritilishidan maqsad oson tushunish uchun va umumiy tushunchalar berildi. Keyingi sonlarda har biriga alohida, pros-and-cons qilib to'xtalib o'tishga harakat qilamiz.

@otabekswe

Kamchilik nimada?

Bir tanishim bilan project qilish bo'yicha suxbat qilib ba'zi fikrlarni muhokama qildik. Hozir ishga topshiruvchilarni fail bo'lishini asosiy sababi ular qilayotgan yoki qilishni istagan projectlarda ekan.

Kimni qarasa E-Commerce, VideoStream ishlarni qilishadi. Vaxolangki bunda projectlarga misollar internetda qalashib yotibdi va eng qiziq tomoni shundaki soxani chala o'rganib olib, kodlarni ko'chirib, tutorialga ergashib qilgan ishini githubga "kerilib" yuklab qo'yishadida "mana shunday ishlar qilganman" deyishadi.

Kompaniyalarda ko'p shunday projectlar qilinishi to'g'ri ammo bu degani siz ham shunday ish qilishiz kerak degani emas. Loyihalar qachon ko'zga tashlanadi qachonki biror ishni nargisidan (loyihadan) yaxshiroq qila olsa. Yoki ko'pchilik qilmaydigan ishlarni qilishda misol uchun DB yaratib ko'rish, tool yaratish generic ishlatish uchun.

Loyiha yasang, faqat o'zingiz uchun emas barcha uchun xizmat qiluvchi loyiha yasang. Bor loyihani qayta yasang, ammo sizniki qaysidir jihatlama yaxshiroq bo'lsin narigisidan.

@otabekswe

#TechTalks 2-soni efirda!

Applied Labs kompaniyasida Software Engineer bo'lib ishlagan, Backend va Data Engineering sohasiga aloqador ko'plab foydali postlar yozgan mexmon - Bobosher Musurmonov bilan o'zgacha suxbat.

Ushbu suhbat ochiq, samimiy va boshqalaridan qiziq bo'ladi, ishonavering. Sizga qiziq bo'lgan savollarni esa izohlarda qoldiring.

Vaqt: 21:00 (Toshkent vaqti bilan)
Sana: 26-Noyabr
Mavzu: Trip to Database internals

@otabekswe

#TechTalks 2-soni

Eslatib o'tmoqchiman, ushbu podcastda xatoliklar bo'lgan bo'lishi mumkin.

Nothing is perfect

deganlaridek podcast yoki talk qilishda yangimiz, aybga buyurmaysiz deb umid qilaman.

Ushbu podcastda asosan Database Internals mavzusida boshlang'ich tushunchalar haqida gap ketgan. Umid qilaman kelasi sonlarda yana ham chuqurroq va yaxshiroq qilishga harakat qilamiz.

Mehmon: Bobosher Musurmonov

Keyingi sonida nima haqida va kimni taklif qilishimizni istaysiz, izohlarda yozing.

@otabekswe