Programming ∀

K8sdagi imkoniyatlar texnik yechim sifatida doyim qoyil qoldirgan. Masalan clustering va scalingga aloqador yechimlar. Undan tashqari juda ko'p integrationlar va flexibility :)

Man ko'rgan solutionlar ichida haligacha hayron qoldiradigan narslardan ko'plari k8s mavjud :) Yana bir ajoyib narsalardan biri esa k3os :) https://github.com/rancher/k3os

✨ Нужно всегда разделять прикладной и системный код (это минимум два слоя реальности), как и роли программистов, описал подробнее. 🧑‍💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе. 👨‍🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.

((a × b) × (c + d × e)) Tokenization haqida

Savol axmoqona bo'lishi mumkin. Ammo masalaga primitiv qaramasligingizni iltimos qilar edim ! Tassavur qiling hamma aytgan gap amalga oshdi 100% Engineer ishini AI qilyabti. Hosh AI uchun ham paragmatistic point of viewlar kerak bo'ladimi :) Yo'q deyishga shoshilmang. Ha deyishga ham.

Yoshligimda yosh edimda :) Biror narsani biror narsaga bog’lab o’rgansam. Haa deman bu narsa faqat shunda bor ekan… Shunday fikrda bo’lib olar edim el qatori 😃 Keginchalik tushunib yetdimki u narsa boshqalarda ham bor va avvalo u narsaning umumiy qolipi yoki izohi mqvjud :) Masalan JS da async/await bor. Bu narsa faqat jsga hos emas. JSdagi asinxron ishlash ham faqat jsga hos emas. Asynchronus programming degan alohida bo’lim bor computer scienceda 🙂 Hammasi ashiyerdan boshlangan hurmatli grajdanlar :)

Ushbu mavzular haqida o'ylar ekanman yana bir narsani tushundim. Bu "paradigm paradox in business". Bu haqida kim qanday fikrlar aytgan ammo mani fikrlarimga ko'ra bu paradoxga aylangan edi. Business uchun ishlaydigan narsa kerak ammo qachondur sifat ham kerak. Paradigm sifatni beradi ammo boshqa narsani oladi biznes esa bularni yoqotish intervalida kasod bo'ladi ))) Qiziq paradoxni qanday buzish mumkin ? Yoki buzish kerakmi ? Lekin bazi holatlarda buzilyabtiku )) Buzilsa nega paradox ? Bu masalaning yechimlari turli ko'rinishlarda va holatlarda kengayib ommalashib borayabti )). Balki tor doirada qolib ketar. Lekin bu paragmatic fanatism emas ekaniga ishonchim komil. Paradigmlarni targ'ib qilayotganlar ularning ko'r ko'rona muhilsi emas. Shunchaki ular boshqalarga qaraganda ko'p savol berishadi. Paradimglar esa ulardagi abstract savollarga aniq javoblarni va yechimlarni taqdim qilgani uchun sevishadi )) Yana boshqalarga bu savollar va ularning javoblari qiziq emas bir kam dunyo :)

Endi so'z yakuni sifatida. Procedurial programmingda siz kompyuterga nima qilishni aytasiz. OOP yoki FPda esa siz kompyuterdan nima hohlayotganingizni aytasiz :) Cho'loq OOP orqali nima hohlaytoganingizni qanday izohlaysiz 😁

Endi o'sha xozirgi cho'loq OOP haqida :) Alan Kay 1998 yilda object haqida birmuncha boshqacha ekanini aytdi va bo'shqa yaxshiroq messaging degan g'oyani izohladi. Maqola uchun havola: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html Xozirgi OOP cho'loq ekanini qanday izohlashadi ? Agar haqiqiy OOP tadbiq qilinsa qanday bo'ladi ? Dasturlash tili dizaynerlari focusni user friently va ma'lum orientationlarga qaratishgan. Shu o'rinda ma'lum nuqtalarda yangiliklar qilishgan. Masalan bazilar orientatsiyalarni perfomance va tezlikga qaratgan bo'lsa yan bazilar sodda syntaxga qaratgan. Undan tashqari bazi tillar aynan maxsus ishlar uchun yo'naltirilan. Yana bazilari esa maxsus paradigmlarni tadbiq qilishga qaratilgan. Ushbu nafaqat tillar formal lagunages nuqtai nazaridan balki ma'lum prioritetlarga qarab baholangan. OOP SmallTak dan boshlangan bo'lsa. Xozirgi mashxur C++ JS, PHP, Java C# kabi tillargacha kirib keldi. Umuman ushbu tillarning asosi C++ :) C++dagi OOP rivojlandi desa ham bo'lar balki ). Ammo to'liq unday emas. O'sha davrlardagi industry tilni soddalashtirishga osonlashtirishga xarakat qildi. Nega ? Oldin code faqat bir tipdagi processorlar uchun yozilgan. Paradigm yoki boshqa narsalarga etibor qilinmagan. Asosiy masala biror narsani bajarishga qaratilgan va bu jarayon anchagina murakkab bo'lgan. Keyin C kabi tillar chiqdi. Ular qaysidur ma'noda cross platform negaki bitta codeni birqancha processorlarga compile qilish mumkin edi. Keyin C++ uni yana osonlashtirishga xarakat qildi. Undan keyin Java/C# C++ ni osonlashtirmoqchi bo'ldi :) Bitta code turli OSlarda ishga tushadigan bo'ldi vaxakzolar :) Tillar osonlashti va abstraksiya yuqorilashdi. Projectlar kattalashdi codebase kattalashdi. Endilikda faqatinga oson til emas balki yana boshqa talablar qo'yila boshladi. Cho'loq OOP esa paradigmni notog'ri tadbiq qilishdan boshlandi. OOP dagi intheritence mavzusini o'qiganmiz. Hosh bu nega kerak ? Inheritence o'zi nima ? U bilan nimaga erishamiz ? Ko'pchilik kamroq code yozish uchun desa yana bazilar kengayishni nazarda tutadi :) Aslida qisman ikkisi ham to'g'ri ammo biz ishlatadigan inheritence noto'g'ri tadbiq qilingan. Objectlar boshqa objectlardan tashkil topishi degani bu classlar boshqa classlardan meros olishi degani emas :) Shu kabi static methodlar. Yoki null g'oyasi vaxakzolar. Bular biz tilni ishlatishimizni oson qilishi uchun ham tadbiq qilingan va hamma bir biridan ko'rib rivojlantirgan. Hosh demak shunday ko'chirmachilik asosida bo'lgan evolution sabab OOP mutantlashdimi ? Qisman ha bu ham talab va taklif masalasi. Man JS ni yoqtiraman ammo undagi mutant OOPni emas. JSda primitive tiplar masalasini o'zi ham biroz og'riqli :) Nima endi bularni hammasi qog'ozda qolaveradimi ? True OOP cho'loq OOPni ustidan kulishga o'ylab topillganmi shunda ? Aslida yo'q, qisqa aytganda OOP ideologiyasi birdaniga ko'p tomonlama rivojlandi. Sciencedan tez kirib keldi katta sayoz auditory yegdi. Bu masalaning yechimi FP kabi. FP auditory xozirgacha yangiliklar qilishadi. Yangicha yechimlar patternalar yuzasidan ko'plab ilmiy maqolalar va izlanishlar olib boriladi. Huddi shunday FP birqancha tillarda sucessfull implement ham qilingan (Haskell, Scala, Elixir). OOPda esa asosan ko'p marketing bo'lib qoldi :) Shu sabab cho'loq OOP shunday ildiz otdi. Ammo FPdagi bazi baxsli mavzular ko'p ayniqsa tiplar genericlar va yana boshqa type theory and computingga aloqador. Shu sababdan ham rivojlanish yuqori. OOPdan esa adabiyotlar xozircha kam izlanishlar ham kam. Ushbu mavzular ham rivojlanadi va yangi tillar paydo bo'ladi. Ammo FP kabi tor auditoryda qoladi katta extimol bilan. Asosiy sabab hamma ham biror yechimni aniq ma'lum formalistik asoslar bilan asoslagisi kelmaydi. Shundoq ham boshqa pointlar ko'p :)

Agar siz paradigmlarni amaliyotda qo'llaydigan darajada bo'lishni xoxlasangiz. Xozirdan versuslarni kamaytirib ko'proq o'qish kerak sababi mavzjula juda katta va keng tarmoqli :)

Masalaning asli ilm fan va biznes mavzusi desa ham bo'ladi. Dasturlash paradigmlari bu fan. Uning bir tomoni xisoblash va informatikaga qarlgani bilan asosi matematika xisoblanadi. Nega aynan Math ? Sababi biz xozirgi o'rganadigan va foydalanadigan narsalarning asosi matematika va undagi g'oyalardan olingan yoki to'g'ridan to'g'ri tadbiq qilingan. Shu bilan birgalikda Math biror narsani isbotlasa juda ko'p holatlarda ushbu yechim o'zgartirib bo'lmaydigan darajada to'g'ri va aniq bo'ladi. Sababi biror masalani yechimi shunchaki og'zaki yoki intuitiv emasligida. Shu o'rida har bir qonuniyatga ma'lum contextlar yuzasidan amal qilinadi va huddi shunday tekshiriladi. Lekin birqacha bosqichli abstraksiya evaziga biz bularni sezmaymiz va shu sababdan ham xozir dasturchi bo'lish uchun matematika muhim emas. Ammo bu mavzudan actual masala yuqorida aytganimday paradigmlar haqida. Keyingi masala esa formalizm masalasi. Paradigmlarda formalizmga qattiq etibor qaratilgan. Shu orqali mavhumlik imkoniyati maksimal darajada kamaytiriladi. Bu esa aniqlik va kam xatolarga eng asosiy sabab. Dasturlashdagi paradigmlarning ko'pida asosan matematik formalizm no'rmalarini sezish mumkin. Bu esa har bir gipotiza yoki yechimning aniqligini ta'minlaydi. Hosh paradigmlar bizga shunday imkoniyatlar taqdim qilar ekan nima uchun asosiy hamjamiyat bularga amal qilmaydi yoki tadbiq qilmaydi ? Bu faqat tor doirasa qolib ketaveradimi ? Paradigmlarda auditory tor ekaniga asosiy sabablardan biri gipotizalar ko'p ekani. Undan tashqari bu mavzularga support kam ekanligida. Qachonki ushbu paradigmlarga etibor darajasi oshadigan bo'lsa shunda yanada tezroq rivojlanadi. Biznes esa dasturlashga asosan instrument sifatida qaraydi. Ushbu nuqta muhim. Nega sababi biznes nimadurga oson erishib oson sotish orqali katta foyda olishni ko'zlaydi. Agar siz biror startup qilsangiz katta extimol bilan juda ko'p narsalarni skip qilasiz. Eng minimal resurslar bilan maksimal rezultat xarakatida bo'lasiz. Shu sabab juda ko'p xolatlarda staruplar trashcode bilan boshlanadi. Endi masala enterprise va anchadan buyon ishlab kelayotgan tizimlarga qolyabti. Startuplardan umid juda kam ekan )) Hosh ildiz otgan tizimlar bu masalaga qanday qarashadi ? Biznes stabillikni hohlaydi. Demak mavjud narsani o'zgartirish uchun critical holatlar bo'lishi kerak. Uchinchi holat esa. Loyihadagi talablar aynan ma'lum paradigmlar asosida yechiladigan yechimlarga bog'liq. Shu o'rinda ushbu resurslarni ta'minlashga imkoniyat mavjud. Bu holatda bemalol yaxshi promotion qilinadi. Kerak bo'lsa yangiliklar amaliyotda sinaladi. Nega engineerlar o'zlari ushbu masalani to'liq implement qilishmaydi. Hosh aynan OOP yoki FP paradigmlari ustida ishlaydigan juda bo'lmasa chuqurroq o'rganishga xarakat qilib amal qiladigan engineerlarning juda ko'pari juda zo'r background egalari. Shu bilan birga o'zlarining ma'lum ambitsiyalari asosida ishlaydilar. Shu o'rinda "Toza OOP yoki FP elegant engineerlar uchun" yoki "OOP yoki FP haqiqiy dasturchilar uchun" Degan fikrlarni ham ko'p aytadilar :) Aytganimday bizneslarning barchasi ham bunday hodimlarni ishga yonlay olmaydi :) Talab bo'lmasa taklif bo'lmaydi... Bu ketishda hechkim biror narsani o'zgartirgisi kelmaydiku. Ha yuqoridagi kabi masalalar sabab paradigmlar tor doirada qolmoqda. Ammo xozirgi kunda paradigmlar populatsiyasi anchagina o'sganini ko'rish muhimkin. 20-30 yil oldin ushbu masalalarga juda kam odamlar etibor qaratgan bo'lsa endilikda xatto bizda ham paradigmlar muhlislari ko'payib borayabti. Endi masalaning eng muhim qismi. Rostdan ham ma'lum paradigmlar shunchalik muhimmi ? Ushbu savolga javobimni aytaman ? Cubeni cube ekgani sizga muhimmi ? Agar shu savolni javobini o'zgarmaydigan darajada bermoqchi bo'lsangiz paradigmlar muhim. Agar sizga cubeni shunchaki qilish kerak bo'lsa. Yana qo'shimcha izoh o'rnida paradigmlarni chuqur o'rganish bizga juda ko'p narsalarga aniq javoblar topishga va har qanaqa darajadagi abstraksiya bilan ishlashga katta yordam beradi.

Nega paragmatic community tor doirada ? Paragmatism qanday darajada bo’lishi kerak ? Bu nega kerak ? Nega judayam tor doira insonlar xozirgi OOPni qoralaydi xato deydi ?

Ushbu post comentiga. Masalalar bor resurslarni yuboring. Aynan web korinishda bolishi shart emas kitob ham bolaveradi. Aynan dasturlash bo’lishi shart emas. Fizika matematika ham bolaveradi.

MongoDB 7.0 Relase candidate :) Ehhe... https://www.mongodb.com/docs/upcoming/release-notes/7.0/

Boshqa sohalardan farqli aynan ITda asosan management juda rasvo. Fikrimcha bizda management maktabi success bo’lishi extimoli bor. Sabab O’zbeklarda muomila va cominication biroz boshqacha. Shuni sal to’g’irlab suniy qismlarni olinsa yaxshi fundament mavjud 😀

O'rtoqlar bir fikr kelib qoldi. Dasturlashni o'rganinglar deb mana ancha bozorni to'ldirib oldik. Endi AyTi korxona ochish, uni yurgizish, buyurtma olish yoki startuplar qilish haqida ham xuddi shu dasturlashga qilgandek bunga ham bosib reklama, targ'ibot qilish kerakmikin, yo'l-yo'riqlarini o'rgatish kerakmikin, nima deysiz? "Treningchilar aytayotgan o'z biznesingizni yo'lga qo'ying va pul ishlang" ko'rinishida emas, chuqurroq va batafsil yo'l yo'riqlar.

Bu haqida alohida yana post yozaman Hudoholasa. O'ylaymanki chartlardan asosiy g'oyani va tushundingiz. Va yana o'ylaymanki bu masala haqida yaxshilab o'ylab ko'rasiz maqola chiqganda discussion uchun. Chart uchun havola: https://my.visme.co/view/kk0zrp1x-untitled-project/#s1

Kun yakuniga shu videoni ko'rib uxlash kerak oma. https://www.youtube.com/watch?v=S6_R5j8hzbY

GRASP GRASP stands for General Responsibility Assignment Software Patterns / Principles. This article is dedicated to covering this topic. Today, most new developers talk about S.O.L.I.D principles blindly. I think they just learn this principle to pass interviews successfully. Before the S.O.L.I.D principle, there was a really popular perception called GRASP. It was dominant at the very time. Most developers today don't know about the principle and event they have never heard of it. So what is GRASP? This principle includes several patterns including Creator, Information Expert, Low coupling, Controller, High Cohesion, Indirection, Polymorphism, Protected Variations, and Pure Fabrication. In this article, I will try to cover some of those which are mostly used. It is a suite of guidelines and principles used to design OO software and assign responsibilities to different classes and objects. These principles help developers build maintainable, flexible and understandable software systems by specifying clear roles and responsibilities to objects. Creator Pattern. This principle states that classes should be responsible for creating other instances of another class if they have the necessary information to do that. This helps you remove unnecessary dependencies between classes. One example of this pattern is the factory pattern. Because this pattern will have any information to instantiate the instances of the class. Another example is order and line items. Line items should be created by order. Because none of the other classes would have information about the line item. (You might have noticed that the aggregate principle in DDD follows that principle). Information Expert. You have to assign a responsibility to the class that has the most information required to satisfy that responsibility. It helps you decide where should put the responsibility. Above example suite for this one. For example, the total count of line items can be gathered through order instead of line item. This principle makes finding a place where is the best to do things easier. Controller. This principle states that you have to assign the responsibility of managing and coordinating user actions to a dedicated controller class. It is all about the coupling and separation of concerns. I would say that correctly implemented layered and component-based architecture is an example of this pattern. Because domain objects shouldn't be dependent on some kind of layers. For example, you should be able to migrate from one database to another without worrying about other layers. Just you have to change only the persistence layer. Low Coupling, High Cohesion. I don't want to write about those principles again, because if you scroll up, you can see two separate articles that cover those principles. Protected Variations. Protect variations in the system by encapsulating the parts that are likely to change. This principle helps isolate changes and their impact on the rest of the system. Before I learned this principle, I had learned a kind of thing called "Encapsulate what varies". This helps to isolate things and reduce the impact of one thing on another one. This kind of thing is accomplished by using abstractions. You can think of this principle as the Single Responsibility principle of the S.O.L.I.D. Indirection. Introduce indirection or intermediate classes to decouple two classes that should not directly depend on each other. This principle helps avoid direct dependencies, making the system more flexible. This is also done by putting abstractions. This principle provides you with low coupling. Pure fabrications. It states that if you cannot find a place to put objects, it is a good idea to follow this principle. Create artificial or "pure fabrication" classes to centralize complex behavior not fitting into other classes. If you cannot find the place where your objects can stay, just create a separate component, module or something which has enough information to accomplish the result. @usmonmasudjonov

SQL ishlatib yurgan davrlarim esimga tushib ketdi 🙂