Biz biladigan zamonaviy dasturlash yuzlab, minglab qavatlardan iborat abstraksiyalar ustiga qurilgan. Natijada, bizda kichikroq, kuchsizroq komponentlardan foydalangan holda minimal mehnat bilan katta dastur qurish imkoniyati bor.

Lekin buning bir "lekin"i bor. Har bir qavat ma'lum darajada resurs isrof qiladi. Bu asosan interface noto'g'ri ishlab chiqilganidan yoki noto'g'ri foydalanilgani uchun sodir bo'ladi (aslida yozib qo'yilgan to'g'ri usulning o'zi yo'q). Bundan tashqari, ko'pchilik low-level interfacelar multi-purpose qilib ishlab chiqiladi (albatta, kamroq mehnat uchun). Bu esa yana resurs yo'qotilishiga olib keladi.

Demak, dastur qancha yuqori darajali bo'lsa shuncha effektivligi past bo'ladi va hardwarening to'la potentsialini shuncha sindiradi. Hozir biz yozadigan dasturlar orqali kompyuterlarning to'la imkoniyatining o'ta kichkina qismidangina foydalanamiz xolos. Agar to'la potensialida ishlata olsangiz, Intel Pentium processori va 2 GB RAM orqali ham "ancha-muncha" ish qilsa bo'ladi (eslasangiz, 50 yil oldin 4 KB RAM bilan inson oyga uchgan).

Shuning uchun low-level tillar high-level tillardan ko'ra ancha tez va effektiv.

Demak, hardwarening imkoniyatlaridan kelib chiqadigan bo'lsak, zamonaviy dasturlarning effektivligi ancha past. Xo'sh, buni to'g'rilashning iloji bormi? Balki.

Bundan 10-15 yillar oldin avtomobil industriyasida xuddi shunga o'xshash holat bo'lgan. 5-6 litrli, 700-800 HPga ega dvigatellar ishlab chiqilgan. Lekin dvigatel effektivligi 30-35% atrofida bo'lgan, ya'ni energiyaning faqatgina uchdan bir qismidan foydalanilgan. Albatta, buni yaxshilash uchun har xil "trick"lar ishlab chiqildi (aerodinamik korpus, turbochargerlar va h.k.), lekin yuqori darajadagi o'zgarishlar juda kam natija berdi.

Keyin sahnaga elektrodvigatellar chiqdi (aniqrog'i, qaytdi). Bu fundamental o'zgarish dvigatel effektivligini 80-90% gacha oshirdi. Narxlar arzonlashdi, rekordlar yangilandi. Aslini olganda, electrocarlar yangilik emas, birinchi marta 19-asrda ishlab chiqilgan. Faqat o'sha vaqt ilm-fan va texnologiyasi elektrocarlar rivojlanishi uchun yetarli emas edi.

Balki, shunga o'xshash jarayon yaqin kelajakda komputerlar industriyasida ham sodir bo'lar? Balki analog komputerlar yana sahnaga qaytar?
Balki kvant komputerlarini general use uchun ishlatish imkoniyati paydo bo'lar?
Kuzatamiz...

Bugun statistics kursida R tili bilan ishlab ko'rdik. Statistics uchun maxsus ishlab chiqilgan til ekan. Shuning uchun computer sciencening qoidalariga tupurib qo'ygan.

Siz computer scientist bo'lsangiz, tilni ko'rib chiqishda ehtiyot bo'lishni maslahat beraman. Allergiya qo'zg'atishi mumkin ))

Bizning sohamizda texnologiya haqida hech narsa bilmaydigan managerdan ko'ra texnologiya haqida ozgina biladigan manager xavfliroq bo'lsa kerak. Sababi, texnologiyadan xabari yo'q manager muhim texnik qarorlarni ishini yaxshi biladiganlarga qo'yib beradi. Bu sohada ozgina, yuzaki bilimi bor manager esa odatda hamma narsani shu bilganlariga qarab o'lchaydi va noto'g'ri qarorlar qilishi mumkin.

Masalan, hozir bizda kerak joyda ham, keraksiz joyda ham microservices qurish "moda" bo'lgan. Bunga asosiy sabablardan biri (lekin yagona sabab emas) monolith bir tiyinga qimmat va microservices hamma muammoni hal qila oladi degan o'ta yuzaki fikrga yopishib olgan managerlar. Lekin bu arxitekturaning "lekin"larini yaxshi bilishmaydi. Natijada development team bosim bilan ishlaydi, mahsulot sifati tushadi va h.k. Lekin boshida shu muammolar chiqishini aytganingda quloq solishmaydi. Oxiri borib yana asosiy "aybdor" bechora engineer bo'lib chiqadi.

P.S. Bu yerda gap aynan bir kishi yoki tashkilotga qaratilmagan. Bu faqat o'nlab managerlar va yuzlab engineerlar bilan gaplashish natijasida olgan xulosalarim.

OOPning kelib chiqish sabablari va OOP falsafasi haqida O'zbek tilida yozilgan yaxshi maqola bormi?

Ok, unda @programming_everyone'dan shu mavzuda yaxshi maqola kutamiz ))

Yangilik!

Esingizda bo'lsa TypeScript va Angular bo'yicha pullik onlayn dars o'tgan edim. Shuning yozib olingan videolarini siz azizlarga tekinga ulashishga qaror qildim.

Darslar kimlar uchun ?
1. TypeScriptni o'rganayotganlar uchun.
2. Angularni o'rganayotganlar uchun.

Ushbu link orqali darslar turgan kanalga ulanishingiz va bemalol foydalanishingiz mumkin. Marhamat.
https://t.me/+M3Dy5G9I7A5kMzQy

Alloh manfaatli qilsin.

P.s: Ba'zi hollarni inobatga olib, darslarni yuklab olish va tarqatishni o'chirib qo'ydim. Bu uchun ma'zur tutasiz.

@JoshDeveloper

Good developers know how things work.
Great developers know why things work.

Steve Souders, Head Performance Engineer, Google, 2013

[Meme] Multithreading.
https://redd.it/yef44g

by @programmer_humor

Bir haftadan beri platformamizda database bilan bog'liq jiddiy bir muammoning sababini topa olmayapman.
Hal bo'lsa interviewlar uchun yaxshi story chiqadi lekin.

P.S. Self note.

Hozirgi kunda biz deyarli hamma ma'lumotni chiroyli va lo'nda ko'rinishda – video, grafik va h.k ko'rinishda olamiz. Bu bir tomondan yaxshi bo'lsa-da, ikkinchi tomondan miyani shunday ko'rinishdagi ma'lumot olishga o'rgatib qo'yadi. Natijada attention span kamayadi. Odam kitob yoki uzunroq maqola o'qishga qiynaladi. Aniqrog'i, sabri chidamaydi. Aslida, bizning avlodning eng katta muammolaridan biri ham shu. Biz hatto o'qishga erinadigan kitobni kimdir sabr bilan yozgan.

Bu yomonmi? Juda yomon. Cal Newport aytganidek, kelajakda yaxshi mutaxassisni yomonidan ajratadigan asosiy faktorlardan biri deep work, attention span bo'ladi.

Engineering Notesda rasm, grafiklardan minimal foydalanishim, iloji boricha hamma ma'lumotni raw text sifatida yozishimning asosiy sababi ham shu. Bir tomondan bu o'zimga attention spanni oshirishga yordam bersa, ikkinchi tomondan readerlarga ham foyda.

Lekin bu yerda yetkazib bera olish juda muhim faktor. Buni uddalayapmanmi? Menimcha unchalik emas. Lekin harakat qilayapman.

Bollar, biz yutamiz.

PHP yomon tilmi?

Yo'q, PHP yomon til emas, shunchaki 90-yillardagi internetga aynan shunday til kerak bo'lgan. U vaqtda web serverlar hozirgidek o'nlab komponentlardan tashkil topmagan. Shunchaki static content serve qilinib, bu content foydalanuvchining browserida render qilingan. PHP esa shu holatda minimal o'zgarishlar bilan server-side processing imkoniyatini yaratdi va bu internetni "next level"ga olib chiqdi.

Xo'sh, o'sha vaqtda ham static content serverdan alohida ishlaydigan til ishlab chiqsa bo'lardiku deyishingiz mumkin. Albatta bo'lardi, lekin PHP internetni o'zgartirib yuborish uchun emas, shunchaki shaxsiy websaytga qo'shimcha imkoniyat qo'shish g'oyasi bilan ishlab chiqilgan til. Rasmus aka shunchaki o'sha vaqtdagi toollardan foydalanib o'zi uchun kichkina til ishlab chiqmoqchi edi. Natija esa o'sha afsonaviy PHP bo'ldi.

P.S. Sizlarga yana bir sirni ochaman: PHPning kengaytmasi aslida Hypertext Preprocessor emas, Personal Home Page'dan kelib chiqqan.

Watch "Keynote: Multithreaded Python without the GIL - presented by Sam Gross" on YouTube
https://youtu.be/9OOJcTp8dqE

Djangoda ishlaydiganlarga savol.
Siz tepadagi qaysi usuldan foydalanasiz va nega?

Muvaffaqiyatsizligidan noliyotgan insonlarni ko'pchiligida bir xatoni ko'rdim:

Intizom yo'qligi.
Boshlagan ishini oxirigacha olib borishmaydi. Ozgina muddat qiyinchilik ko'rib, darrov sabrsizlik qilib tashlab qo'yishadi. O'z ustida ishlashni davomiy olib borishmaydi. Bir necha hafta yoki oy qilishadi, keyin yana sabrlari tugab, dangasalik qilishadi, yutqazishadi. Oxirida esa umrlarini katta qismi o'tgan bo'ladi, ular esa hech narsaga erishishmagan. Chunki hech birida oxirigacha borishmagan bo'ladi.

Shu narsa ulardagi muvaffaqiyatsizlikka sabablardan biri.

@UmarSadullayev

"Sifatli softwarega kuchli toollar orqali emas, kuchli dasturchilar orqali erishiladi." – degandi David West.
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".

Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.

Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.

Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.

P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).

1. OOPning asosiy afzalligi dasturchi dastur haqida "odamga o'xshab" o'ylashiga imkon berish. Kompyuterga o'xshab emas.

2. Shunchaki data va behaviour birlashsa bu hali object degani emas.

3. Dasturda classlardan foydalanish bu hali OOP degani emas.

OOPni o'rganishda eng ko'p uchraydigan xatolardan biri OOP konseptlarini biror dasturlash tiliga bog'lab o'rganish. Bu xato, sababi OOP bu paradigm, dasturlash tillaridan ancha yuqorida turadigan konsept. Til esa OOPni kodda implementatsiyani ko'rsatib berish uchungina ishlatilishi kerak deb hisoblayman.

"Java OOP" emas, "OOPning Javadagi ko'rinishi" bo'lishi kerak aslida.