StartUp va yoshlar

O‘zbekistonda StartUp qilayotgan yoshlar ko‘paygan. Bu juda yaxshi holat. O‘zining shaxsiy tijorati (biznesi) bo‘lishi juda zo‘r.

Yoshlarimiz tirishqoq, qiyinchilikdan qo‘rqmaydi, ishini oxiriga yetkazishga harakat qiladi. Bu xislatlar hammada ham bor emas. Bersang yeyman, bermasang o‘laman - kayfiyatidan chiqib olganimiz quvonarli holat.

Ammo bitta "Lekin"imiz bor.

StartUp qilish qoidalari va talablari bor. Buni ko‘pgina markazlar o‘rgatib kelmoqda. Masalan, StartUp Garage. Yangi boshlayotganlarga yo‘l xaritasi (Roadmap) berib, har bir bosqichni tushuntirib kelishmoqda. Bu fundamental bilim va busiz ish yurishi qiyin.

Hatto yaqinda StartUp Garage o‘zining yopiq eco-tizimini hamma uchun ochdi (Founders Community). Endi hamma tekinga a’zo bo‘lishi mumkin. StartUp asoslarini o‘rganishi, tanish-bilish orttirishi mumkin.

Meni o‘ylantirgan narsa esa, yoshlarning ish yuritishi.

O‘zini CEO deb bilgan StartUpchilar, g‘oyadan boshqa ish qilmagan. Menga ham ko‘p yozishadi. 2-3 asoschi bilan suhbat qilib koʻrdim, gaplari qiziq:

- Oka, manga CTO kerak-de.
- Nima uchun?
- Shu man o‘ylagan narsani yasab beradi. Hammasini o‘zi boshqaradi. TZ yozishdan bozorga kirishgacha qilib beradi.

Yoki:
- CTO misiz? Manga CTO kerak. Kompyuterga aloqador loyiha o‘ylaganman. Shuni qilib berish kerak.

G‘oya borligi yaxshi, g‘oya hammada bor.

Shu g‘oyani tushuntirib bera olish, uni amalga oshirish uchun qadamlarni yozib chiqish, shu qadamlarni bajarish uchun harakatni boshlash, har kuni g‘oyani loyihaga aylantirish ustida ishlash hammaning ham qo‘lidan kelmas ekan.

Hurmatli StartUp asoschilari:

- Agar StartUpʼingiz hali g‘oya shaklida bo‘lsa, iltimos, StartUp qurish asoslarini o‘rganing.

- IT mutaxassisi qilib beradi, men shuni ustida biznes qilaman, - degan fikrdan qayting.

- G‘oyamni yasayman, sarmoya (investitsiya) olaman va sotaman, - deb kichik fikrlamang.

G‘oya bormi? BIror muammoni hal qiladimi? Raqobat qila olasizmi? Ko‘lami katta emasmi? Tez bozorga kira olasizmi? O‘zi umuman bozorga kirish imkoni bormi?

kabi savollarga javob topib qo‘ying.

Nazariy asosini bilmasdan ish boshlasangiz 90/10 ning 90 tomonida bo‘lib qolasiz.

StartUp boshlaganingiz zo‘r, to‘xtamang. Parallel nazariy tomonini ham o‘rganing. Biz sizga yordam beramiz. Faqat savollar va taqdimot (pitch)ga yaxshi tayyorlaning. Vaqtni nazorat qiling.

Foydali va asosli StartUpʼlarimiz koʻpayvursin!

15.09.2025 London
@DrAlgorithm

Assalomu alaykum.
Mazza qilib Shaytanatni Juma kuni tugatdim. Oʻziyam 10 iyuldan beri oʻqibman. Aybga buyurmisizlar. Zoʻr yozilganiga koʻp ishlarim qolib ketdi. Bu kanal ham huvillab qoldi.
Miyya ochilganiga Shanba kuni oʻtirib bir project boshladim. MongoDB + EFCore da. Qiziq boʻlsa githubda boʻlishaman )

https://github.com/mirzaevaziz/modest
Ancha randalab qo'ydim

Qahva (kofe) - halolmi?

Qahva ajoyib narsa. Ishing tushmasa, maza qilib xotirjam yurasan. Lekin u bilan tanishsang va ayniqsa yaqin o‘rtoq bo‘lib qolsang, bo‘ldi, kunda bir necha bor hayoling u bilan band bo‘ladi.

Gemini bilan qahva haqida gaplashib qoldim. Qiziq narsalar bilib oldim.

O‘zimizcha "Coffee shop"ga chiqib kelaylik deymiz. Aslida Qahva chiqqan vaqtda "qahvaxona" atamasi chiqqan ekan (1500 yillar).

Ilk qahva 9 asrda Efiopiyada ixtiro qilingan ekan.

15 asrlarda Yamanda qahvani yetishtirish va sotishni boshlashgan. Bu esa Arablar diyorida qahvaning keng tarqalishiga sabab bo‘lgan. Ilk "Qahvaxona"lar ham o‘sha davrda ochilgan ekan. Bu davrlarda So‘fiylar tungi ibodatda qoim turish uchun, uhlab qolmaslik uchun iste’mol qilishgan ekan.

1511 yilda qahva Makkada harom qilinadi. 1524 yilga kelib, Usmonli sultoni Sulton Sulaymon I davrida, bosh Mufti Mehmed Ebüssuûd Efendi (al-İmadi) fatvosi bilan halol qilinadi.

16 asrda qahva Eron, Misr, Suriya va Turkiyaga tarqagan.

17 asrga kelib qahva Ovrupo davlatlarida ham keng tarqala boshlagan. Londonda 300 ta qahvaxona bo‘lgan ekan. Qiziq narsa aytaymi?

Hozirgi Co-working markazlarining vazifasini 17 asrda Qahvaxonalar bajargan ekan.

G‘oya egalari, san’at egalari, tadbirkorlar va boshqa turli soha odamlarini birlashtirish va yangi loyihalarni muhokama qilish uchun joy bo‘lgan ekan.

Ba’zi qiziq faktlar:

1. Qahva donalarini ko‘pchilik meva deb o‘ylasa kerak. Aslida esa u qahva daraxti mevasining danagi ekan.
2. "Mocha" qahvasi. Mocha so‘zi Yamandagi Moxa portning nomi bo‘lgan.
3. 1675 yilda Angliya qiroli Karl II qahvaxonalarni taqiqlagan.
4. Qahva so‘zi arabcha vino so‘zidan olingan, - deyiladi.
5. Qahvada 1,500 ta ta’m bor ekan. Vinoda esa 200 ta.

Coffee (en) <- kaffei (dk) <- kahve (tr) <- qahva (ar).

Qahvasiz o‘zingizni yaxshi his qilsangiz, ichmasdan yurganingiz ma’qul. Qahvaga o‘rgangan bo‘lsangiz, 18:00dan keyin ichmang.

Salomat bo‘ling

Rasm: Mahalladagi qahvaxonada rasmga oldim. Yozilgan yozuvi yoqdi.
- Yetarli qahva bilan dunyoni boshqarar edim.

22.09.2025 London
@DrAlgorithm

Xozirch Integration testlarini yozib bo'ldim.
Bugun bitta muammo chiqdi. Mongodbda auto transaction by default ishlamasakan. Misol db contextga 1 dan ko'p entity change qilinsa xato beryapti.
Xozircha Database.AutoTransactionBehavior = AutoTransactionBehavior.Never; qilib qo'ydim.
Yana vaqt bo'lganda shuni chuqurroq tahlil qilib ko'raman.
Tuningiz haytli bo'lsin!

This setting (Database.AutoTransactionBehavior = AutoTransactionBehavior.Never) in EF Core when working with MongoDB (or any non-transactional provider) is not just a toggle — it has important caveats. Let’s go deep into what this means, why it exists, and the potential issues you should watch out for.

⸻

🔎 What AutoTransactionBehavior Does

In EF Core (SQL providers like SQL Server, PostgreSQL, etc.):
• By default, SaveChanges wraps your operations inside a transaction if one isn’t already active.
• This ensures atomicity: either all changes succeed, or none are committed.

MongoDB is different:
• MongoDB doesn’t use EF’s transaction system natively.
• Transactions exist in MongoDB only for replica sets and sharded clusters (introduced in MongoDB 4.0), and even then EF Core providers may not fully integrate with them.
• So the EF Core MongoDB provider often disables transaction wrapping by default or allows you to set this explicitly.

⸻

⚠️ Potential Issues When Using AutoTransactionBehavior.Never

1. Loss of Atomicity
• SQL DB: if you call SaveChanges on 5 entities and the 3rd insert fails → all inserts roll back.
• MongoDB + Never: each document is sent individually; if the 3rd fails → the first 2 stay written.
👉 This leaves your DB in a partially saved state, inconsistent with your domain model.

⸻

2. Concurrency Issues
• Without a transaction, if multiple processes/threads update related documents at the same time, you can get:
• Lost updates (last writer wins).
• Race conditions (e.g., two services decrementing stock, both reading the same old value, then writing incorrect new values).
• Normally EF Core’s transaction would serialize this, but Never disables that safeguard.

⸻

3. Cross-Collection Inconsistencies
• Example: You create an Order and related OrderItems.
• With Never, if Order inserts succeed but OrderItems fail → orphaned data.
• MongoDB doesn’t enforce foreign keys, so cleanup is manual.

⸻

4. No Retry on Failure
• SQL providers + EF Core transactions can be retried as a unit if transient errors occur.
• With Never, MongoDB inserts/updates might fail in the middle, requiring you to implement your own retry + compensation logic.

⸻

5. Eventual Consistency Surprises
• If your app logic assumes that after SaveChanges the DB is in a valid, fully persisted state, that assumption is broken.
• For example:
• Service A: Saves Product and Inventory documents.
• Service B: Immediately queries both.
If Inventory failed to persist, Service B sees half-saved state.

⸻

6. Harder Unit of Work Semantics
• EF Core’s DbContext is supposed to represent a unit of work.
• With Never, SaveChanges no longer guarantees atomic unit-of-work behavior.
• That undermines the DDD principle of aggregate consistency.

⸻

7. Provider-Specific Transaction Support Gaps
• MongoDB does support multi-document transactions on replica sets/shards, but:
• Not all EF Core MongoDB providers implement them.
• If they do, you must use AutoTransactionBehavior.WhenNeeded or explicit BeginTransaction().
👉 By forcing Never, you guarantee transactions are never used, even where they are possible.

⸻

8. Debugging & Error Recovery Complexity
• Example: A batch update fails mid-way.
• With transactions, you know nothing changed → just retry.
• With Never, you must:
1. Detect which documents succeeded.
2. Roll back manually or compensate forward.
3. Handle side effects (like external events fired for already-saved docs).

⸻

✅ When is Never Safe/Useful?

You might want this if:
• Your operations are idempotent (safe to repeat).
• Each document is independent (no strong relationships).
• You rely on MongoDB’s natural eventual consistency model.
• Performance matters more than strict atomicity (skipping transactions can be faster).

⸻

🧩 Best Practices if You Must Use Never
1. Design for Idempotency
E.g., if inserting PaymentHistory, use natural/document IDs that prevent duplicates if retried.
2. Apply Outbox Pattern for event publishing so half-saved states don’t fire inconsistent domain events.
3.

Use Compensating Actions: If Order fails, delete any saved OrderItems, or mark Order as “incomplete.”
4. Limit SaveChanges Scope: Save only one aggregate root per SaveChanges call to reduce risk.
5. Enable Application-Level Transactions: Wrap SaveChanges in custom logic that ensures consistency across documents.

⸻

🔑 Bottom Line

Setting Database.AutoTransactionBehavior = AutoTransactionBehavior.Never in EF Core MongoDB:
• Removes EF’s guarantee of atomicity.
• Exposes you to partial saves, race conditions, and inconsistencies.
• Makes you responsible for implementing consistency, rollback, and retry logic manually.
• Only safe if your model and operations are naturally idempotent or single-document focused.

EPAMning Maxtumqulidagi ofisiga anchadan beri kelmaganakanman. Joylashgunimcha 15 minut ketti ))))

Kun boshlanish ritualini boshladik )))

EPAMchilar ucun party 🎉🎉🎉

5 oʻrin oldi mani komandam. Lekin zoʻr boʻldi. 1 martta AWS da ishlashim edi.