HeatMap

✅ HeatMap(Issiqlik xaritasi) - Juda ko’p projectlarda HeatMapdan foydalanish katta ustunlik beradi.
Yaqinda bir sherigimiz, HeatMap orqali ajoyib project qilibdi. Toshkent hududida sodir bo’layotgan avtohalokatlarni xaritaga tushirib chiqibdi.

✅ Link: http://aziza2027.pythonanywhere.com/

✅ Bu ma’lumotlar orqali eng ko’p avtohalokatlar bo’layotgan nuqlardagi muammolarni aniqlash ancha osonlashadi. Unda 4 xil xususiyatlar asosida nuqtalar berilgan.

P/s: Shunga o’xshash project qilib o’z portfoliongizni boyitishingiz mumkin. Bu keyinchalik ishga kirishda katta yordam bo'ladi.

**Iloji boricha Kompyuterda ochishga harakat qiling. Voice chat davomida aytilgan heatmap haqida

Source: DeCoder_uz

Everyday I see different types of blogs in telegram and wanna try new style of blog posting, but then wanna try something new again.

Advice to myself: take a break and if that idea is not going out of your head, then you should definitely try it.

#thoughts

@AdamSaidov

I love comparing programming staff to life (sometimes I call it philosophy)

As you know we have 3 versions of a product, they are :

Your job -> Local server
Investments -> Testing Server
Savings -> Production Server

So, how I compare it, let's imagine that local server, where you build your life as you want it and you do investments in testing server, if something goes wrong you work on your life mistakes (local server). If that doesn't help you can get all datas and all staff you need from production server, where is your savings and you will use it, when you really need it.


@AdamSaidov

As I promised next live coding we will be doing to do app, by the help of framework Django . And I hope If I can manage my time till the end of may we will see Crud and DRF

So the date is 20 th of May at 8 pm

Discord server: https://discord.gg/FQVgMb64
@AdamSaidov

The song that I'm repeatedly listening to)

I've decided to transfer date of the live coding, cause of my deadlines in project. I will announce the date sooner.

Thanks for you understanding.

Thanks to all my friends for supporting me in my difficult times and special thanks to my lovely Mom and grandma ❤️

I'm 19 now

Когда вы хотите снять крутое фото, вы снимаете несколько раз, но это не значит, что вы получите ожидаемый результат.

Так в жизни также, вы стараетесь фоткать с разных ракурсов и получаете, то что посчастливилось.

Как говорилось: Удача - когда навыки + шансы в одном моменте.

Till that moment I was just copy pasting regex patterns. But I really needed to understand what the f**k this regex actually do in ma project, so here it is 👇🏻

https://tyler.caraza-harter.com/cs320/f20/materials/lec-21.pdf

Да, мы все принадлежим людям, как ресурсы, а точнее, как продукт, акции или облигации.

Родители - наши первоначальные инвесторы
Родственники - люди, которые служат инвесторам
Друзья - покупают акции, проще говоря акционеры
Знакомые - покупают облигации
Хейтеры - люди которым не нравится ваш продукт или они из-за вас обанкротились

Так вот, если вы хотите, чтоб вас уважали, часто вспоминали, поздравляли и прочее, работайте над продуктом иная версия работайте над собой, чтоб ваши акции только взлетали.

PS: Может это все прозвучало грубо, прошу прощения такая правда

- "Самый большой обман - не всё так просто. И эту ложь тебе повторяют постоянно.
Все хотят чтобы ты сдался. Говорят: не всё так просто. Все просто. Если говорят, что ты чего-то не можешь, сделай это, и всё. И ты поймёшь, что всё очень просто. И так было всегда."

- (с) Винни Пациенца

PostgreSQL ma'lumotlarni qanday saqlaydi?

Ko'pchilikning hayolgia keladigan birinchi javob – jadval(table)larda. Lekin shu table o'zi aslida nima va qanday ishlaydi?

Birinchi bilishimiz kerak bo'lgan narsa – PostgreSQLda biz kiritadigan ma'lumotlar tablening o'zida saqlanmaydi. Table bu ma'lumotlarning o'zini saqlaydigan emas, balki o'sha ma'lumot qayerda saqlanganini ko'rsatib turadigan heap nomli ma'lumotlar tuzilmasi (data structure)dan iborat. Bu qaysidir ma'noda frontendga o'xshash: o'zida ma'lumot yo'q, lekin uni qayerdan olishni biladi.

Xo'sh, unda haqiqiy ma'lumotlar qanday saqlanadi?
PostgreSQL haqiqiy ma'lumotlarni heap tuple (yoki shunchaki tuple) nomli alohida tuzilmalarda saqlaydi.
Heap tuple bu (odatda) tabledagi bitta record(row) saqlangan obyekt. Ya'ni bitta rowdagi qiymatlar bitta tuple sifatida, ketma-ket joylashadi. Va har bitta tuplening o'zining IDsi bor. Biz biladigan jadvalda biz qo'shgan ustunlardan tashqari yana bitta ustun – TID(Tuple ID) ham bor va aynan o'sha qiymat shu rowga tegishli ma'lumotlar qaysi tupleda turganini ko'rsatadi.

*qo'shimcha

Demak, ma'lumotlar tupleda saqlanishini bilib oldik. Bir qancha tuplelar birlashib, page yoki blokni tashkil qiladi. Bitta pagening o'lchami odatda, 8 KB bo'ladi va har bitta page fayl sistemasida bitta fayl sifatida saqlanadi. Albatta, bu faylda tuplelardan tashqari bir qancha metadata ham saqlanadi.
Shunday qilib, bitta tabledagi ma'lumotlar bir qancha (kamida bitta) pagelarda saqlanadi.

Yana bir gap, doimiy xotirada RAMga o'xshab istalgan joydagi istalgan baytni to'g'ridan-to'g'ri ololmaymiz. Birinchidan, doimiy xotira RAMga o'xshab, addresslanmagan. Ikkinchidan, har bir baytni asosiy xotiradan alohida-alohida o'qib olish ancha "qimmat"ga tushadi. Shuning uchun doimiy xotiraga bir marta borganda ko'proq ma'lumot olib qaytish kerak. PostgreSQL asosiy xotiradan ma'lumotlarni page bo'yicha ko'chiradi, ya'ni bitta faylni to'liqligicha yuklab oladi.
Bu degani, agar bizga bitta pagedagi faqat 1 ta qiymat kerak bo'lsa ham, butun pageni ko'chirib olishga majburmiz.

Ma'lumotlar to'liq tuplelardan saqlanadimi? Yo'q.
Katta hajmli ma'lumotlarni doimiy xotiradan ko'chirib olish ancha resurs oladi. Shuning uchun ularni faqatgina eng kerakli vaziyatlardagina ko'chirib olish kerak.

Masalan,
SELECT * FROM test_table WHERE id = 3;
mana shu query ishga tushganida agar indeks bo'lmasa id bo'yicha izlash uchun hamma id larni olishimiz kerak. Lekin tepada kelishganimizdek, bizga faqatgina id kerak bo'lsa ham butun boshli tuple va o'sha tuple joylashgan blokni ko'chirib olishimiz kerak.
Agar keyingi ustunda 1 GB hajmli fayl to'g'ridan-to'g'ri saqlansa, shunchaki bitta IDni (aslida faqatgina izlash uchun) olish uchun butun boshli faylni ham yuklab olishga to'g'ri keladi.

Xo'sh, katta hajmli ma'lumotlarni tupleda saqlay olmasak, unda qanday saqlaymiz? Oddiy yechim. Shunchaki ma'lumotni boshqa joyda saqlaymiz va tupleda faqatgina shu ma'lumot turgan joy manzilini saqlaymiz. Tupleni RAMga ko'chirib olayotganda esa 1 GBli ma'lumotni emas, faqatgina uning addressini olamiz. Qarabsizki, six ham kabob ham kuymaydi.
Umuman olganda, PostgreSQL hatto varchar va textni ham tupleda saqlamaydi. Xuddi tepada aytilganidek ularni ham alohida saqlab, tupleda ularga pointer saqlaydi.

Albatta, bu ma'lumotlar juda yuzaki va aslidan biroz o'zgartirilgan(osonroq tushunish uchun). Lekin o'ylaymanki, bu qisqa maqola kim uchundir shu mavzuda izlanib ko'rishga turtki bo'la oladiganlar darajada foydali bo'ladi.