LeetCode 2023 Badgelarni tarqatishni boshhlapti!

Bugun biroz vaqt ajratib telegramdagi o'zbek tilidagi biror texnologiyaga oid communitylardagi savollarga qarab chiqdim. Aksariyat savollarda umuman ma'no yo'q. Savol yozgan odam nima qilayotganini o'zi ham bilmaydi. Aksariyat savollar matni shu darajada didsizlik bilan yozilgan-ki, o'qiging kelmaydi.

Bu bilan kimningdir ustidan kulmoqchi emasman. Aytmoqchi bo'lganim, ko'pchilik aytayotgan "O'zbekistonda dasturchilar ko'payib ketdi" dagan gapga qo'shilmayman. Dasturchilar haliyam juda kam. Qolgani yaxshi dasturchi bo'lishni hatto xohlamaydigan* yigit-qizlar. Xuddi oliy ta'limdagidek: Talabalar soni bir necha baravar ko'paygan bo'lsa ham sifatli kadrlar soni juda oshib ketgani yo'q. Shunchaki diplomi borlar ko'paydi.

Men o'zimni kuchli dasturchi deb hisoblamayman, lekin tepada aytilgan holatni yaxshilash uchun bir-ikkita o'ta oddiy tavsiyalarim bor.

1. Dasturlash sohasini ilm-fan deb qabul qiling. Dasturlash 6 oylik kursda yodlab, keyin har kuni takrorlaydigan ish emas. Ilm-fan yodlashni emas, tushunishni va fikrlashni talab qiladi. Biz foydalanuvchilar emas, balki yangilik qiluvchi, quruvchilarmiz.

2. Fundamental bilimlarga e'tibor qarating. Djangoni, Reactni yoki Flutterni o'rgangan odam dasturchi bo'lib qolmaydi. Algoritmlar, komputer arxitekturasi, tarmoqlar va hokazolarni o'rganish framework o'rganishdan ko'ra sizga ko'proq narsa beradi. Va albatta, matematika (frontendchi bo'lsangiz ham). Ayniqsa, calculus, linear algebra, discrete math kabi bo'limlardan yaxshi xabardor bo'lmasdan turib yaxshi dasturchi bo'lmoqchi bo'lsangiz chuchvarani xom sanabsiz. Matematika kerak emas deydiganlar uchun bir kinoda murabbiyning bolalarga aytgan gapi bo'lardi: "Agar uyda dadangiz golib yoki mag'lublik hech narsani hal qilmaydi degan bo'lsa unda u mag'lublardan biri".

3. To'g'ri odamga ergashing. Aksariyat holatda har hafta ko'zni qamashtiradigan reklamalarda chiqadigan dasturchilardan ko'ra sohaga ancha oldin kirib, past-balandini ko'rgan, lekin ijtimoiy tarmoqlarda ko'p aktiv bo'lmagan tajribali dasturchilardan ko'p narsani o'rgansangiz bo'ladi. Ustoz Saidolim aka men bilgan shunday tajribali insonlardan biri.

4. Ustozlarni hurmat qiling. Ularning maslahati va vaqti qimmat turadi, shunga yarasha munosabatda bo'ling. Gap faqat vaqt va maslahatda ham emas, umuman, ilmli inson sifatida hurmat qiling. Bo'lmasa kosangiz oqarmaydi ))

5. O'rganish uchun to'g'ri resurs tanlang. Youtubedagi 2 soatlik tutorialdan ko'p narsa o'rgana olmaysiz. Sohaga oid kitoblar, dokumentatsiya, ilmiy maqolalarni o'qing. Yaxshi mutaxassislarning bloglarini kuzatib boring, podcastlarini eshiting. Kitob yoki dokumentatsiya o'qish yoqmayaptimi? Unda haligi zo'r ish, katta maoshdan ham umidni uzavering. Jon kuydirmasang... deyishadi-ku.

6. Ko'proq savol so'rang va javob toping. Chuqurroq kirib ko'rishdan qo'rqmang. "Buyog'i juniorga kerak emas" degan narsa yo'q. Natijada boshida biror narsani o'rganish uchun ko'proq vaqt ketsa-da, keyinchalik bu vaqt keragidan ortiq darajada o'zini oqlaydi.

7. Imkoni bo'lsa universitetda o'qing. Yaxshi universitet hech qaysi kursda olib bo'lmaydigan tajriba va imkoniyatlar beradi.

P.S. Bular sohaga yangi kirganlar o'rasida men eng ko'p ko'rgan xatolarga yechimlar. Aslida, har biri haqida alohida post yozish mumkin.

@boboshersnotes

JVM arxitekturasi boʻyicha maqolalar toʻplami boshlandi. Memory Management ham shu toʻplamni ichiga kirib ketadi. Batafsil: https://medium.com/@soataliyevj/jvm-arxitekturasi-3443a485d3d1
#java #jvm

@Jakhongir_Soataliev

"Unit testing" nima? U qanday ishlaydi?
3/20

Mastercarddagi birinchi vazifam unit test yozish va loyiha testlar bilan qoplanganlik darajasini (test coverage) 20% dan 75-80% oshirish ekanini aytgandim oldinroq. Shu vazifani tugatganim (bir oycha oldin) sababli o'zim yaxshiroq tushungan narsalar haqida aytib ketmoqchiman.


"Unit test" o'zi nima?

Rasmiyroq ta'rifga ko'ra "unit testing" — bu dasturni individual tarzda testlash mumkin bo'lgan mayda qismlarga, unitlarga bo'lib, ular to'g'ri ishlashini (avtomatlashtirilgan) testlar orqali tekshirish.

Unit testing yoki Test Driven Development (TDD) nimaligi tushuntirilgan video yoki maqolalarni ko'rsangiz u yerda asosan "uchburchak yuzasini topish", "o'lchovlarni konverstatsiya qilish" kabi oddiy va real loyihalarda juda kam uchraydigan misollarni ko'rasiz. Bu narsadan qochish uchun men o'z ta'rifimni MVC freymvorklar, aniqrog'i Service-Repository Pattern bilan tushuntirib beraman.

Yuqoridagi pattern bo'yicha asosiy biznes logika Service classlar ichida yotadi. Ular o'z navbatida ba'zi kichik kalkulyatsiyalar uchun yordamchi (utility) classlarni chaqirishi yoki bazalar bilan ishlash vaqtida repositorylarga murojaat qilishi mumkin.

Unit testlarni yozishda esa siz o'zingiz uchun "unit" nima ekanini aniqlab olishingiz kerak. Service metodlarini testlamoqchi bo'lsangiz, uni yordamchi classlar bilan qo'shib testlamoqchimisiz yoki faqat metodlar o'zinimi? Lekin, odatda unit testlar ichiga Repository — baza bilan ishlash kiritilmaydi. Sababi unit testlar oddiy, tez va yengil bo'lishi kerak.

O'zingiz uchun unit nima ekanini aniqlab olgandan keyin uni boshqa bog'liqliklardan (dependency) izolatsiyalab, haqiqiy unit holatga keltirib olish kerak. Buning uchun bir yo'la Dependency Injection va Mocking haqida tushuncha olib ketish kerak.

Dependency Injection — bu shunchaki biror class to'liq ishlashi uchun boshqa bir class yoki uning metodiga bog'liqligi bor degani. Masalan Controller class Service classga dependent, Service Class Repositoryga.

Mocking — bu "unit"ning bog'liqliklari o'rniga soxta / mock obyektlar yaratib, ularning metodlarini o'zingiz xohlagan ko'yga solish )

Shulardan kelib chiqib:

Unit Testing — bu dasturingizning siz aniqlab olgan unitlari uchun ularning bog'liklari qanday ishlashini hisobga olmagan holatda (avtomatlashtirilgan) testlash

Unit testing qanday ishlaydi / yoziladi?

Endi qisqacha MVC va Service-Repository Pattern uchun unit test (deyarli) qanday bo'lishini ko'rsatsam:

@Mock
UserRepository userRepository;

@AutoWired
UserService service;

@Test
public void testSave() {
User user = new User(1, "Name", "Surname");
given(userRepository.save(any()).willReturn(user);

User savedUser = service.save(userDto);
assertEquals(userDto.getId(), savedUser.getId());

then(userRepository).should().save();
}

Bu kod to'liq ishlamasa ham, tushunib olish uchun yetarli.

1. Birinchi qismda biz Repository uchun Mock yaratib olyapmiz va uning save() metodi chaqirilganda nima qaytishi kerakligini aytyapmiz. Ya'ni bu yerda real holatda dependency to'g'ri ishlaydimi yo'qmi bizni qiziqtirmaydi. Biz testlayotgan unit — Servicening save() metodi.

2. Shundan keyin, aytaylik request parametrlaridan yasab olinadigan userDto obyektini service save metodiga berib yuboramiz va qaytgan natijani biz bergan parametr bilan mosligini testlab ko'ramiz.

3. Oxirida service class rostdan ham repositoryning save metodini (faqat bir marta) chaqiryaptimi testlab olamiz.

Bu qisqacha Unit Testing nimaligi va u MVC dasturda qanday ko'rinishi haqida edi. Keyingi postda Unit Test, Testing o'zi nima uchun kerakligi haqida qisqacha aytib o'taman.

#softwareengineering

Professional blog | Linkedin | Shaxsiy blog

print("Hello world")

Bu kodni biz yaxshi bilamiz.
Lekin bu postni o'qiyotganlarning 99% qismi bu kod aslida qanday ishlashini bilmaydi. Ha, aynan shunday.
To'g'ri, Python interpreter kodni o'qib, execute qiladi deyishingiz mumkin, lekin o'sha execute qilish o'zi nima?
Buni siz yozgan bir qator koddan boshlab CPU, RAMda nima sodir bo'lishi-yu, kompyuteringizdagi har bitta atom qanday harakatlanishigacha tushuntirib bera olasizmi? Katta ehtimol bilan, yo'q.

Endi o'rinli savol: Hatto "Hello world" qanday ishlashini bilmaydigan dasturchi qanday qilib sun'iy intellekt yaratishi mumkin?

Gap shundaki, dasturlashda biz hamma narsani noldan, aniqrog'i nolgacha chuqur o'rgana olmaymiz. Xo'sh, unda o'sha chuqurlikni qanday yopamiz? Axir uy tomdan boshlab emas, asosdan boshlab quriladi-ku. Javob – abstraksiya orqali.
Ya'ni biz ichki ishlash tizimini bilmaydigan (ko'p hollarda bilish zarur bo'lmagan) narsalarni shunchaki ishlaydi deb hisoblaymiz yoki qanday ishlashi haqida aslidan farq qiladigan, sodda tushunchaga ega bo'lamiz (aslida bu ham biroz pastroqdagi abstraksiyalar yig'indisi).

Masalan, eng oddiy backend server yozayapsiz va u request kelganida databasedan ma'lumot olib, response yuboradi.
Buni qilish uchun request o'zi nima, uni qanday olamiz, database qanday qilib ma'lumot beradi va hokazolarni bilishimiz shart emas. Ular "shunchaki" o'z vazifasini bajaradi deb hisoblaymiz.

Natijada bizda tizim qanday ishlashi haqida minimal ma'lumot bilgan holda uni ishlab chiqish imkoniyati paydo bo'ladi. Ya'ni aynan abstraksiya sabab komputerdagi har bitta atom qanday ishlashini bilmay turib ham dastur ishlab chiqa olamiz.

Lekin rivojlanishni xohlasangiz, abstraksiyalarni buzib kirishdan qo'rqmang. Yanada chuqurroqqa tushish sizga ko'proq narsani ko'rish va o'rganish imkonini beradi. Natijada biror texnologiya haqida oldin bilgan narsalaringiz noto'g'ri ekanini va u aslida boshqacha ekanini tushunasiz. Oldingi tushunchalaringiz esa kulguli darajada oddiy tuyulishni boshlaydi.
Yana ozgina pastroqda tushsangiz, o'sha "batafsil" bilganlaringiz ham juda oddiy ko'rinadi.

Lekin abstraksiyalarni buzib, chuqurroqqa tushish bizga o'zi kerakmi?
Bilmadim, bu sizga bog'liq. Shaxsan menga end-user ishlatadigan mahsulot ishlab chiqishdan ko'ra boshqa dasturchilar ishlatadigan toollar ishlab chiqish yoqadi. Menga "chuqurroqda" ishlash yoqadi.

Update: Juda yaxshi misol berilgan komment yozildi, biroz o'zgartirib, postga qo'shib qo'yaman:
Har kuni mashinani o't oldiramiz va haydab, ishga boramiz. Lekin buning uchun mashina qanday ishlashini bilish shart emas.
Agar mashinadan faqat ishga borish uchun foydalansangiz, shu yetarli.
Lekin siz mashina tuzatadigan yoki ishlab chiqaradigan mexanik bo'lsangiz ichki qismlar va ular qanday ishlashini albatta bilishingiz kerak bo'ladi.

2. Savdogarning jumbog´i

Rimdan mol bilan qaytgan savdogar qaroqchilar tomonidan ushlab olindi. Savdogar muloyimlik bilan rahm-shafqat so'radi, ammo qaroqchilar uni qo`yib yubormoqchi emas edi.

-- Do'stlar, - dedi u, - to'g'risini aytsam, mening vazifam juda oddiy va men uni sizlarga sodda qilib taklif etaman.

Uning gaplari iliq qabul qilindi. Chizmasida ko'rsatilgan rejani ochdi va tushuntirdi:

... davomi keyingi xabarda

https://t.me/DrAlgorithm/443

Savdogarning jumbog´i

Rimdan mol bilan qaytgan savdogar qaroqchilar tomonidan ushlab olindi. Savdogar muloyimlik bilan rahm-shafqat so´radi, ammo qaroqchilar uni qo`yib yubormoqchi emas edi.

-- Do´stlar, - dedi u, - to´g´risini aytsam, mening vazifam juda oddiy va men uni sizlarga sodda qilib taklif etaman.

Uning gaplari iliq qabul qilindi. Chizmasida ko´rsatilgan rejani ochdi va tushuntirdi:

yuqoridagi rasmga qarang

bu yerda oltmish to´rtta shahar va ularni bog´laydigan yo´llar tasvirlangan. Bundan tashqari, safarning boshlang´ich nuqtasi qora katak bilan ko´rsatilgan ekanligini tushuntirdi.

Savdogar barcha shaharlarni 15 ta o´tishda tashrif buyurishi kerak edi.
Har bir shahar bir marta va faqat bir marta kirib chiqilishi va har bir o´tish to´g´ri chiziqda amalga oshirilishi kerak edi. Siz o´z yo´lingizni istalgan joyda tugatishingiz mumkin, lekin rasmning pastki qismida qisqa yo´lning yo´qligi tasodifiy emasligini unutmasligingiz kerak - bu erda hech qanday yo´l yo´q.

Rasmda berilgan qora katakdan boshlab, barcha shaharlarni o`tib chiqa olasizmi? Eng ko´p 15 marta burilish mumkin ekan?

Savol raqami: 40221

Javob topmasdan izohlarni ochmang. Javobini koʻrib qolsangiz qizzigʻi qolmaydi.

Iltimos: javobni topgan boʻlsangiz koʻrinmas hira (spoiler) qilib tashlang. Boshqalar ham urinib koʻrishsin!

https://t.me/DrAlgorithm/443

box.com dan ish uchun rad (reject) oldim.

Maqola: https://telegra.ph/Boxcom-dan-rad-javob-oldim-03-07

Biz qanday esdan chiqaramiz yohud eng muxim ko’nikma.

TLDR: Bu maqolada Amsterdamdagi kitob do’koni, eslab qolishish ko’nikmasi va uning muximligi haqida so’z yuritiladi. Barchaga ham tavsiya qilmayman. Juda uzun va qiziqarsiz bo’lishi mumkin siz uchun.
Agar yo’q men baribir o’qiyman desangiz unda xavola orqali maqolani o’qing.

@khamidulla_inoyatov

Recently had a post-lab interview at Epam Systems, here is the questions that i was asked:
https://telegra.ph/Java-Technical-Interview-Questions--Epam-Systems-06-02

This is about bug in binary search implementation in java which is detected 9 years later

JVM internals:

https://youtu.be/ZBJ0u9MaKtM?si=r-Ba6zxkywIMpOl7

Recently had an interview for Junior Java Engineer role at Vention Teams. Below you can find sample questions that i was asked during interview:

https://telegra.ph/Vention--Interview--Junior-Java-Engineer-07-31

Hi, recently had a Project Interview at Epam Systems, below you can find the questions:

https://telegra.ph/Java--Project-Interview--Epam-Systems-09-11