Engineering Notes

Function-based viewlarda renderga context dicrionary o'tkazasiz. Bu dictionary backenddan templatega jo'natiladigan hamma datani ichiga oladi.
Class-based(generic) viewlarda bu ishni get_context_data() methodi bajaradi. Default holda bu yerda faqat get_queryset() methodi qaytargan queryset bo'ladi. Qo'shimcha context qo'shish uchun methodni override qilish kerak:

posts = Post.objects.all()
authors = Author.objects.all()

def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["authors"] = authors
context["posts"] = posts
return context

Templateda {{posts}}, {{authors}} ko'rinishida ishlataverasiz.

Authentication uchun biror unique, ya'ni butun table bo'yicha takrorlanmaydigan column kerak bo'ladi. Umuman olganda har bir userning takrorlanmas id'si bor, lekin bu userning o'zi uchun eslab qoishga noqulay va sensitive data hisoblanadi(kimdir shu joyini noto'g'ri deyishi mumkin).
Shuning uchun birorta unique column qo'yish kerak. Bu turli xil: email, username, telefon raqam va hokazo bo'lishi mumkin.
Django default User modelida auth uchun username ishlatilgan. Agar boshqa biror narsadan foydalanib auth qilmoqchi bo'lsangiz, custom User model yozsangiz bo'ladi.

Yana bir maslahat, dynamic urlpattern bilan ishlaganda ehtiyot bo'ling. Iloji bo'lsa, static pathdan keyin ishlating. Tartibda ham static urllarni birinchi qo'yganingiz yaxshi.
'',
'detail/<int:pk>/',
'results/<int:pk>',

shaklida. Bo'lmasa, so'rov yuborgan url'ingiz aytgan manzilingizga yetib bormasidan boshqa dynamic urlpatternga "tiqilib" qolishi mumkin.

Bir narsani tushuning, hozir men u kishining muammosini yechim berganim bilan, uning ildizi o'z holicha qoladi. Ertaga rekursiyaga bog'liq yana biror error chiqqanda, yana yordam so'rashga majbur bo'ladi.
Maqsadim, xatoni qanday tuzatishni emas, u qayerdan kelganini ko'rsatish. Shunda keyingi safar o'zi muammoni topa oladi.
Agar qarmoq bo'lmasa baliqlar albatta bir kun tugaydi.

Bo'ldi, ortiq flood qilmoqchi emasman. Fikringizni hurmat qilaman.

Redis in-memory database bo'lgani uchun, juda tezkor va asinxron ishlay oladi. Odatda, caching yoki async messanging(xuddi biz hozir yozishib turgan telegram chat) uchun ishlatiladi. Bir kishi yozgan xabar parallel ravishda qolganlarga ham yetib boradi, yangilash shart emas.

Celery esa message queue uchun ishlatiladi(lekin ishlatib ko'rmaganman). Ya'ni guruhda hozir birdaniga 50 kishi yozsa, ularni tartib bilan handle qilish uchun.

Saytdagi url namunalari, ya'ni "yo'llar".
Masalan, "login/" yoki "posts/14/" url bu yo'l. Siz o'sha yo'ldan borganingizda sizni qaysidir view kutib oladi. U esa manzil deyishingiz mumkin. Masalan, "products/" nomli url patternga biriktirilgan view sizga barcha productlar ro'yxatini chiqarishi mumkin.

Agar siz borgan "yo'l" oxirida hech kim sizni "kutib" olmasa, 404 error chiqadi :-)

Masalan, passwordni "chiqarib olish"ni oldini oladi.
Hash qilingan password bilan tekshirishda kiritilgan password o'sha key bo'yicha hash qilinib, natija databaseda saqlangan password bilan tekshiriladi, ya'ni databasedagi passwordni o'z holiga qaytarib bo'lmaydi.
Admin panel orqali boshqa userlarning passwordini ko'rsangiz, sizga hash holatida ko'rsatiladi.

Ya'ni security ga qanday yordam beradi demoqchiman har xil attack lar bor ekan shularni biron tasini oldini oladimi ? Xss nimi yoki sql injectionni oldini oladimi shuni nazarda tutgandim?

Assalomu aleykum password ni hash lash securityni qaysi jihatini oshiradi?

Authentication uchun butun table bo'yicha unique bo'lgan field(column)dan foydalanish kerak bo'ladi.
Djangoning default User modelida username fieldi unique, ya'ni takrorlanmas. Bitta username bilan 2 kishi ro'yxatdan o'tolmaydi.
Agar buni o'zgartioqchi bo'lsangiz custom user model yozishingiz kerak bo'ladi. Shunda email, telefon raqam yoki boshqa biror field bilan authentication qilsangiz bo'ladi.

Bu fikrlar faqat bir tomonlama.
Javaning qanchalik stabil va kuchli til ekanidan xabarim bor(ko'p bo'lmasa ham). Lekin bu degani boshqa tillar "axlat" degani emas.

Pythonda faqat rasm-videolarni yuklash mumkin? Yo'q, siz(muallif) pythonda faqat shuni qilishni bilasiz. Bizning firmada Banklar, Zavodlarning boshqaruv tizimlari kabilar Pythonda qilinadi va hozircha hammasi yaxshi ishlab turibdi.

Python platforma tanlaydi? Sizga kim aytdi projectni tog'ridan to'g'ri serverda yuriting deb? Container, virtual machine degan narsalar bor.

Shu o'rinda "ortiqcha vaqt, harajat" haqida. Siz serverga qo'yish uchun ba'zi qo'shimcha sozlashlarga ketadigan vaqt va harajatlarni aytdingiz. Normal jamoa javada 6 oyda tayyor qiladigan loyihani xuddi shu darajadagi jamoa Pythonda 2 oyda qilishi mumkin. Bu ham o'sha "ortiqcha ish, ortiqcha pul, ortiqcha vaqt"ga kiradimi?

Pythonda faqat Instagram kabi kichkina vebsaytlar yoziladi, Javada IBM SPSS kabi katta tizimlar yoziladi debsiz. Shu joyida shunchaki texnologiya giganti bo'lgan googlening bir shiorini keltirib o'taman:  “Python where we can, C++ where we must.”
Yoki bu ham kichkina vebsaytmi?

P.S. Tepadagilarni yozishdan maqsad python javadan kuchli yoki java kuchsiz deyish emas. Shunchaki har bir tilning o'z vazifasi va imkoniyatlari bor ekanini eslatib qo'yish. Faqat bir tomonlama analiz qilmaslikka chaqirish.
Agar siz biror tilning imkoniyatlarini bilmasangiz o'sha til kuchsiz degani emas.

urls.py ni ko'rsatingchi.
Aftidan, delete urldan teparoqda dynamic (slug, id kabi) url bor va siz jo'natgan request o'sha urlga "tiqilib" qolgan.
Ya'ni urlda "delete/" deb yozgan bo'lsangiz ham shu urlga kelayotgan request teparoqdagi "<int:id>/" dan o'tib keta olmayapti.
Agar shunday bo'lsa, dynamic urldan oldin boshqa kalit so'z(masalan, "detail/<int:id>/") ishlating yoki dynamic urlni eng oxiriga qoldiring.

Dasturchilar orasida "Googling is a skill." degan ajoyib gap bor.
Ya'ni qanday izlashni bilish ham bilim, hatto san'at.
Bu ishingizni nohoyatda yengillashtiradi.
Google bilan do'stlashib oling :-)

Bitta conceptni tushunishingiz kerak:
User(va boshqa model) objectlari ham databaseda saqlanadi, admin panel yoki boshqa pageda emas. Ular faqat databasedan olib, chiqarib beradi.
Demak, ma'lumotlar bazasidan o'chirish userni admin panel yoki boshqa pagedan ham o'chiradi.
Bazadan o'chirish uchun o'sha user objectini olib, uning delete() methodini chaqirishimiz kerak.
User objectini esa templatedan kelgan user.id orqali olamiz. Bizda user.id bor, eni user objectini olamiz:

user = User.objects.get(id = id)
# ikkinchi id biz templatedna olgan id.
user.delete()

Biladiganlarim bo'yicha aytadigan bo'lsam,

Qachon ishlatmaslik kerak:
1. WHERE bilan ishlatilganda too many rows qaytaradigan querylarda(masalan, ManyToManyda).
2. Ko'p yangilanib turadigan columnlarda(masalan , mijoz hisobidagi mablag').
3. Mumkin qiymatlar soni cheklangan holda(masalan, django fieldda choices ishlatganda).
4. Bir xil qiymatli(shu jumladan null) rowlar ko'p bo'ladigan columnlarda (1- va 3- bandlardan kelib chiqib).
5. Rowlar soni ko'p bo'lmagan tableda

Qachon ishlatish kerak:
1. WHERE bilan ishlaganda odatda 1(yoki juda kam) ta row qaytaradigan querydagi rowlarda(SELECT * FROM users WHERE email = 'example@gmail.com' (UNIQUE bo'lsa database o'zi index qo'shadi).
2. WHEREda odatda birga ishlatiladigan fieldlar uchun multicolumn index (masalan, authentication uchun odatda username bilan password birga ishlatiladi).

Va ANALYZE qilish. Django qanchalik ko'p analyzedan foydalanishi haqida xabarim yo'q.
Har safar nimadir implement qilib, oldingi performance bilan compare qilib ko'rish. Bu orqali qaysi usul ko'proq foydali ekanini va qayerda ishlatmaslik kerakb bilib olasiz.

P.S. Bu faqat shaxsiy izlanishlarim :-)

Agar server kuchsizroq bo'lsa, bitta appni ko'plab alohida portlarda ishga tushirish ham yaxshi natija bermaydi(CPU bilan RAM requestlarga turib berolmasa).
Iloji bo'lsa hardwareni ham bittadan ko'paytirish kerak.

pre_save bu signal. Model objectining save() methodi chaqirilishidan oldin biror boshqa kodni yurgizadi. Menimcha hozir boshqa narsani so'rashdi. Yana bilmadim.

Birinchi usul odatda, userning ma'lumotlarining bir qismini alohida saqlashda ishlatiladi.
Masalan, o'qituvchi uchun model yaratmoqchisiz. Uning ismi, yoshi o'qitadigan fanlari, sinflari, maoshi kabilar alohida modelda saqlanadi.
Email, username password kabi faqat login uchun kerakli detallar User modelida qoldirilib narigi model bunisiga ulanadi.

Umuman olganda, sizning User modelingizdagi barcha fieldlar default User modelida ham bor.

Siz User nomli model yozgansiz, ammo djangoning o'zida ham shunday nomli model bor.
Hozir user login qilganda siz yaratgan model objecti sifatida emas , djangoning defaul User modeli objecti sifatida kirayapti.
Sizda (kamida) 2 ta variant bor:

1. Modelingizga boshqa nom berish(masalan, Profile) va uni one to one relationship orqali default User modeliga bog'lab qo'yish.

2. Custom User model yozish. Bu nisbatan qiyinroq, ammo siz kutgan natijani beradi.

Channel created