Hi guys I take New certificate from Coursera


@itsoftware_uz

Hayrli kun

@UzAcharya_Bot

@axroraibot

@Uzwikifindbot

Shu botlarni test qilib koringlar

Hozirda Stabil ishlab turubti serverda

Serverga botni yoki website qo'yishni bilmasangiz sizga zo'r maslahat:
Bu tutoriallar har doim ham yordam bermaydi va esingizda turmaydi.

Lekin qiyinchilikka uchrab izlanib o'rgansangiz hech ham yodingizdan chiqmaydi, shu sababli biror joydan VPS yoki VPC sotib oling (tekini bo'lmasin) va botingizni qo'yishga urining birinchisida hammada ham ishlab ketavermaydi lekin harakat qilaversangiz izlansangiz juda tez o'rganib olasiz va keyingi safar yana qandaydur tutoriallar bilan o'ralashib qolmaysiz

O'rganishning eng tez va samarali yo'li bu Xato qilish

Assalomu aleykum hayrli kun hammaga


Mening bir loyiham test rejim uchun ishga tushirgan edim

Agar oramizda Acharya Universiteti Talabalari bolsa tekshirib korishinglar mumkin


Web sahifa acharya.coderboys.uz


Telegram Bot : @auidbot


Kirib ko'rib ishlatib kamchilik taklif va izohlaringizni

@axrorback ga yuborishingiz mumkin


Loyiha nomi: Acharya Students Platform

Dasturchi : bento.me/axrorback

200 dan ortiq kitob yozdim barbir
Meni emas ayollarni fatvosi oʻtib kelyabdi…!

Shayx Muhammad Sodiq Muhammad Yusuf hazratlari

🇺🇿 Ko‘pchilik dasturchilar kod yozishni biladi. Ammo ular loyihadagi bilim va tajribasini keyingi dasturchiga uzata olishadimi?

Keling, ochiqchasiga gaplashaylik. Shu kungacha ko‘plab zo‘r kod yozadigan dasturchilar bilan ishlaganman...
Lekin loyiha topshirish masalasiga kelganda ular juda sust bo‘lishgan.

Loyihani tark etishdan oldin shunchaki bir nechta login-parol va qisqagina xabar orqali bilimlarini sizga uzatishadi: “O‘zing tushunib olasan.”

❌ Hech qanday hujjat yo‘q.
❌ Arxitektura qarorlarining izohi yo‘q.
❌ Koddagi maxsus holatlar haqida hech qanday izoh yo‘q.

Natijada esa, keyingi dasturchi loyiha ichiga xuddi detektiv kabi kirishga majbur bo‘ladi.
Soatlab quyidagilarni tushunishga harakat qiladi:

✅ Nega buni shunday qilgan?
✅ Bu sozlama qayerdan chiqyapti?
✅ Bu servis qanday ishlaydi o‘zi?

Manimcha, bu holat juda ko‘pchilikda uchrab turadi. Eng yomoni - ko‘plab dasturchilar buni normal hol deb o‘ylashadi.
Ular loyiha topshirilmasdan qoldirilishida hech qanday muammo ko‘rishmaydi.

Aslida-chi?
Yaxshi dasturchi faqat kod yozishni biladigan emas.
U - muloqot, hujjatlashtirish va hamkorlik qiladigan odam bo‘lishi kerak. Ayniqsa, loyihani tark etayotgan paytda.

Bilimni topshirish - bu sizning ishingizni bir qismidir.
Agar boshqa dasturchi ishingizni davom ettira olmasa - demak, ushbu loyihada sizni ishingiz hali tugamagan.

Loyihani tark etayotganda loyihdagi bilim va tajribani keyingi dasturchiga uzatish uchun quyidagilarni qilish zarur deb o'ylayman:

✅ To‘liq va aniq handover (topshirish) ro‘yxati tuzush
✅ Arxitektura qarorlari va ularning izohlarini shakllantirish
✅ Kod bazasi bo‘yicha tushuntirish sessiyalari - bir nechta "zoom call" yetarli bo'ladi
✅ Loyiha holatini yaxshilab topshirish - imkon va vaqt bo'lsa albatta

Agar siz jamoa yetakchisi, CTO yoki yolg‘iz dasturchi bo‘lsangiz - standartni o'zingiz uchun yarating.
Indamasdan jimgina tark etish - sizning oxirgi “commit”ingiz bo‘lmasin.

Siz bu borada nima deb o‘ylaysiz?
Bunday holatlarga siz ham duch kelganmisiz?

————————————————

🇺🇸 Most developers can write code. But can they transfer knowledge?

Let’s be honest. I’ve worked with many developers who were great at writing clean, working code...
But when it came to handing over a project, they became surprisingly passive.

Before leaving, they’d just drop a few login credentials and send a short message like: “You’ll figure it out.”

❌ No documentation
❌ No explanation of architectural decisions
❌ No context around special cases in the code

As a result, the next developer has to dive into the project like a detective, spending hours trying to figure out:

✅ Why was this done like that?
✅ Where is this config coming from?
✅ How does this service actually work?

In my experience, this happens way too often.
And the worst part? Many developers think this is completely normal.
They don’t see any issue in walking away without a proper knowledge transfer.

But here’s the truth:
A good developer isn’t just someone who can write code.
A good developer communicates, documents, and collaborates - especially when they’re about to leave a project.

Transferring knowledge is part of your job.
If someone else can’t continue your work - you didn’t finish it.

When leaving a project, I believe developers should take the time to do the following:

✅ Create a clear and complete handover checklist
✅ Document architecture decisions with reasoning
✅ Walk through the codebase — even a couple of Zoom calls can help
✅ Properly wrap up the project if time and capacity allow

If you’re a team lead, a CTO, or even a solo developer - set the standard for yourself.
Leaving in silence should not be your final commit.

What do you think?
Have you experienced this kind of situation too?

@axrorback


bento.me/axrorback

Tuyaqushga oʻxshaydi bazi odamlar uch desang tuyaman deydi
Yuk tashi desang qushman deydi

Darajangiz oshganini yaxshi savollar berishni boshlaganingizdan sezsangiz bo’ladi.

Bilimi va darajasi uncha kuchli bo’lmagan odamga yordam berish juda qiyin. Nimani hohlayotganini undan sug’urib olish kerak.

Odatda savol tahminan quyidagicha bo’ladi: “Aka, shu ishda muammo bo’lyapti. Nima noto’g’ri ketgan bo’lishi mumkin?”

😮‍💨

Tahminan 1035 ta narsa noto’g’ri ketgan bo’lishi mumkin. Hammasini aniqlashtirib olishimizga to’g’ri keladi endi.

- Aynan qayerda muammo?
- Nima qilsang chiqyapti?
- Bunday qilib ko’rdingmi?
- Bunaqa qilib ko’rdingmi?
- Mana bu yerda yozilgan narsalarni o’qib chiqib, sinab ko’rdingmi?

“Darajangizni bilmoqchi bo’lsangiz, siz berayotgan savollarga boq” ©️

@axrorback

Dasturchi sifatida sizning ishingiz faqatgina o‘zingiz uchun belgilangan vazifalarni yaxshi bajarishdan tashkil topmaydi. 

Ayniqsa daraja oshgan sari boshqalarni ishini to‘g‘ri qilishga yordamlashishning ahamiyati oshib boradi.

Bu narsa “Pull Request” larda ayniqsa ko‘zga tashlanib turadi. Kimdir qarab o‘tirmasdan approve qilib yuboradi. Kimdir yaxshilab tekshiradi. 

Menda oldinlari kimdir mendan Pull Requestini tekshirib berishini so‘raganda “O‘zi yaxshilab tekshirib ko‘rgan bo‘lsa kerak”, “Tezroq approve qilib bu insonni unblock qilishim kerak” degan xayollar o‘tar edi. Natijada yaxshilab tekshirmasdan tezda tezda approve qilib yuborar edim.

Hozir esa erinmaslikka harakat qilaman. Qanchalik ko‘p vaqt olishidan qat’iy nazar ko‘nglim to‘ladigan darajada tekshirib chiqaman. Tushunmagan joyim bo‘lsa shu joyini yaxshilab tushuntirib berishini so‘rayman. Ba’zida hattoki birov tomonidan yozilgan kodni o‘zimga yuklab olib IDE xususiyatlaridan foydalanib yaxshiroq tushunishga harakat qilaman.

Natijada esa hamkasblarning sizga bo‘lgan hurmati yanada oshadi. Bu esa darajani yanada oshishiga to‘g‘ridan to‘g‘ri hissa qo‘shadi.

@axrorback

Kuchli o’qituvchining eng zo’r hususiyatlaridan biri bu nimani o’rgatishdan tashqari nimani o’rgatmaslikni ham bilishida.

Ba’zida mavzularni umuman tashlab ketish yoki dasturning ohirrog’iga surish o’quvchilarga katta yordam beradi. Ularni adashtirib yubormaydi.

Hayrli kech hammaga
@axror_contactbot
Bu botni bugun ishga tushurib qoʻydim shunchaki zerikishda yozgan edim men bilan aloqa va men haqimda malumotlar beradi hamda anonim (yashirin) habar ham yozishingiz mumkin

Biz doim odam dasturchilarga muxtojmiz.

©️ Thomas Dohmke (CEO of GitHub)

PS: Dasturlashni o'rganishdan to'xtamang!

#tavsiyation

Yotvolib kod yozish sizga axmoqlikdan boshqa hech narsa bermaydi.  Atrofni o'rganing. Dasturchi zo'r kod yozadigan inson emas balkim yaxshi yechim topuvchi bo'lishi kerak.  Har bir detal sizga as qotishi mumkin.

Yaxshi dasturchi kerak bo'lmasa kod yozmaydi. Buyuk dasturchilar esa iloji boricha kamroq kod yozadi.

@axror_contactbot

Universitetimiz uchun tayyorlagan Telegram botim
Yani @UzAcharya_Bot
Kamchiliklari tuzatildi va yangi yangilanishlar qóshildi test qiling



@UzAcharya_Bot


Fikr va mulohazalaringizni esa


@axror_contactbot ga yóllashingiz mumkin

IDlar nimaga kerak?

To‘g‘risi, dasturlashni boshlaganimda men ham shu savolni ko‘p o‘ylardim. Axir foydalanuvchi nomlari takrorlanmasa, yoki email manzillari ham noyob bo‘lsa, unda nega alohida ID kerak?

Aslida esa, ID juda muhim. Buning asosiy sabablari esa quyidagilar:

1. Ma’lumotlar bilan ishlashni osonlashadi.
Qidirish, o‘chirish, yangilash yoki filtrlash amallarini bajarishda oddiy raqamli yoki noyob ID ancha tez va samarali ishlaydi.

2. ID biznes mantig‘idan mustaqil bo‘lishi kerak.
Shunday qoida bor. Ya’ni foydalanuvchi nomi, email yoki boshqa “ma’noli” qiymatlar hech qachon ID vazifasini o‘tamasligi kerak. Chunki ular o‘zgarishi mumkin, biznes jarayoniga bog‘liq bo‘ladi. ID esa doim barqaror/stabil/o'zgarmas bo‘lib qolishi lozim.

Shuning uchun ham, dastlab IDning foydasi ko‘rinmasligi mumkin. Ammo vaqt o‘tib loyihalaringiz murakkablashgani sari, IDlar sizni ko‘plab chalkashliklardan asrab qoladi.

Ko‘p yangi boshlovchilar bu narsani tushunmaydi. Chunki ular hali IDning “front ortidagi” kuchini ko‘rmagan bo‘lishadi. Shuning uchun IDlardan foydalanish — bu nafaqat texnik zarurat, balki yaxshi dasturchilik odati hamdir.

🔑 Primary Key (PK) nima?
Primary Key (PK) — bu jadvaldagi har bir qatorni noyob aniqlovchi qiymat. Ya’ni biror ma’lumotni 100% aniq tanib olish uchun ishlatiladi.
PK sifatida odatda ID ustuni ishlatiladi.

🔢 Number ID (1, 2, 3, 4…)
Eng oddiy usul: 1, 2, 3, 4 kabi avtomatik ortib boradigan sonlar.

Afzalliklari:
- Juda tez va samarali qidiriladi.
- O‘qilishi oddiy.
- Ko‘p DB-larda default qo‘llab-quvvatlanadi (AUTO_INCREMENT, SERIAL).

Kamchiliklari:
- Agar bir nechta server/baza bilan ishlasangiz, IDlar to‘qnashishi mumkin.
- Tashqariga (URL, API) chiqarish xavfli — chunki foydalanuvchi boshqa IDlarni taxmin qilishi mumkin.

🔤 UUID (Universally Unique Identifier)
UUID — bu uzun noyob satr (masalan: 550e8400-e29b-41d4-a716-446655440000).

Afzalliklari:
- Global darajada noyob (turli serverlarda ham to‘qnashmaydi).
- Xavfsizroq (IDlarni taxmin qilib bo‘lmaydi).
- Distribyutsiya qilingan tizimlarda qulay.

Kamchiliklari:
- Juda uzun (saqlash va indekslash ko'proq joy egallaydi).
- O‘qish va ishlatish sonlarga qaraganda noqulay.

Qaysini tanlash kerak?
- Oddiy loyiha, bitta server → raqamli ID yetarli.
- Katta tizim, ko‘p server yoki public API → UUID yaxshi tanlov.
- Ba’zi joylarda ikkalasi birgalikda ishlatiladi: ichkarida raqam, tashqariga UUID.