Engineering Notes

Va shaxsan men bunaqalarni haligi infolo'ttivozlardan ham xavfliroq deb hisoblayman jamiyat uchun. Soxta biznes trenerlar sodda odamlarning ishonchiga kirib, sodda xalqni shilgan bo'lsa bular davlatning ishonchiga kirayapti.

Oxirgi paytlarda 1-2 ta o'zi ham tushunmaydigan conference yoki hackatonlarda qatnashib, o'zini zo'r mutaxassis deb hisoblaydiganlar ko'payib ketayapti. Umrida bir qator kod yozmagan IT project managerlar, matematikani bilmaydigan AIchilar, bittagina prezentatsiya bilan falon so'm yutib olgan ixtirochilar, umrida startup qilib ko'rmagan startup maslahatchilar, ... . 2-3 tasi bilan gaplashib ko'rdim, nuqul osmondan keladi, lekin gapida ma'no yo'q. Lekin shular mediaga chiqib oddiy xalq tushunmaydigan 2-3 ta termin qo'shib gapirsa odamlar "o'g'lim/qizim shunga o'xshasin" deb comment yozadi. Menga nima, o'zlarini xursand qilib yuraversin deyman-u, lekin hamma e'tibor shularda bo'lgani uchun aslida qo'lidan ish keladigan yoshlar soyada qolib ketayapti. Aslida shu qo'lidan ish keladigan qatlam haqli bo'lgan imkoniyatlar haligi "mutaxassis"larga berilib, bir tiyinga qimmat ishlarga sovurilib ketayapti.

Bu postni ko'rolmaslik deb hisoblasangiz, mayli, shunday bo'lsin.

3 kishi tanlab, kursga access berildi. Kimlar yutganini commentda ko'rsangiz bo'ladi. Hammaga rahmat.

Bu kursning o'rniga 3 kishiga Jahongir akaning "Building your own Python web framework" kursini sovg'a qilmoqchiman. Bu kurs sizga nega kerakligi haqida qisqa komment qoldiring. 1 bet insho shart emas, 1-2 ta gap yetadi. Ertaga kursni so'raganlar orasidan 3 kishini tanlab olaman.

Dasturlash sohasiga oid o'zbekcha resurslarni ko'paytirish tarafdoriman, lekin terminlarni ko'r-ko'rona tarjima qilishga qarshiman. Database – berilganlar ba'zasi, list – ro'yxat, class – toifa, bunaqa terminlarni tarjima qilish butunlay keraksiz va cringe deb hisoblayman. Bir ustozim aytgandi, 89-yil o'zbek tiliga davlat tili maqomi berilganidan keyin shunchalik "o'zbeklashib" ketganmiz-ki, gazetalarda traktor "o'rmalovchi" deb nomlanishni boshlagan deb. Bizda ham ba'zi terminlarni "o'rmalovchi" qilib yuborishayapti.

6-7 oydan beri LinkedInga kirmayotgandim, bugun qayta kirib ko'rdim. Cringe bo'yicha TikTokdan ham o'tib ketibdi.

Oldinroq Husseinning OS kursini 3-4 kishiga sovg'a qilaman degandim. Kursning sifatini ko'rib bu kursni yana 3-4 kishiga olish unchalik yoqmayapti. Nimani tavsiya qilasizlar?

Great overview of convolution neural networks:
https://www.youtube.com/watch?v=UZDiGooFs54

Ko'pchilik adashadigan narsa Jahongir aka aytayotgan ishini yoqtirmaslik bilan o'z ishiga "passion" yo'qligi orasida katta farq borligi. Ba'zilar bir sohaga kirib, ozgina vaqtdan keyin bu soha mengamas ekan deb chiqib ketadi. Buni qanday bilding deb so'rasangiz "falonchi akaga o'xshab maza qilib o'rgana/ishlay olmadim" deydi, ya'ni harakat qilsa qo'lidan keladi lekin *hozircha* passion yo'q. Menimcha sohaga haqiqiy mehr (ya'ni ular izlayotgan passion) shu sohaga minglab soat vaqt sarflagandan keyin, vaqt o'tishi bilan keladi.

Masalan, men biznesni yoqtirmayman, lekin 3-4 yil shu sohada qattiq mehnat qilsam ishonchim komil, ishimdan rohat olishni boshlayman. Lekin masalan, 3-4 yil filolog bo'lib ishlasam ham baribir bu soha yoqmaydi keyinchalik ham. Yoki Chomskyga o'xshab linguistikani ham konkret model sifatida ko'rishni boshlayman😂

Knowledge of the day: Ham sandwich theorem

Yaqinda kimdir shu mavzuda savol so'ragandi, hozir kimligini eslay olmaganim uchun linkni kanalga qo'yayapman.

https://youtu.be/7G4ipM2qjfw?si=bbX58y4sHJd5Gd1e

👷Microservices are not silver bullet

👎 You likely don't need microservices if:

1. You aren't ready to handle increased complexity: more infrastructure💰, more error handling, extra tools for debugging and logging 🧠
2. You aren't familiar with bounded contexts and think that "micro" in a microservice is about "doing one job" 🤯
3. You have no problems that microservices solve.

👍 You likely need microservices if:

1. You have multiple teams working on the same code base and there are constant conflicts. Responsibilities are not clear 😖
2. Some parts of the systems have slightly different performance and durability requirements ⚡️
3. The system overall is too complex so you need big abstractions 🧠
4. You want part of the system to use different tech stack.

#microservices #architecture

Universitet tomonidan tashkillashtirilgan "Integrable Systems Related to Reflection Groups in Algebra, Geometry and Topology" mavzusida o'tkazilayotgan yozgi maktabda qatnashayapman. Anchadan beri pure math bilan shug'ullanmay qo'yganim sezilayapti. Mavzularni yaxshi tushunish va orqada qolib ketmaslik uchun anchagina mehnat qilishga to'g'ri kelayapti.

By the way, I've watched Hussein's OS course recently. In short, I'm not satisfied with the course. I was expecting it to be way better considering the time it took to be released. I'll try to write a detailed review later on.

Alright, let's discuss. Leave your opinion in the comments about these 5 points (why it might or might not be the case). Also, you can introduce your own predictions for incoming PL trends.

Mobile internetni yoqasan, o'lgudek sekin. fast.com'ga kirib tekshirib ko'rasan, yaxshi ishlayapti deydi. Keyin VPN bilan qaytadan kirib ko'rasan, endi sekin ko'rsatishni boshlaydi. Qolgan saytlarga kirib ko'rasan, bir xil ishlayapti. VPNda muammo yo'q, o'z-o'zidan 1 ta variant qoladi: ataylab sekinlatishayapti. "Mana, zo'r ishlayapti" deyish uchun faqat fast.com'ni tez ochib berishadi. O'ynab qo'yay bundaychikin operatorlaringga.

5 programming language trends to look for in the next 10 years:

1. Moving (back) from developer comfort to code efficiency. We've created an insane amount of unnecessary abstractions in the name of "making developer's life easier". So much so that only a fraction of total computing power is spent to do the actual work in traditional software systems, the rest is simply wasted to deal with abstractions. With the current generation of computer hardware reaching to its maximum potential, the only real way to improve performance is gonna be making the software more efficient by chopping of as much unnecessary layers as possible, unless a breakthrough happens in hardware industry.

2. Immutability and statelessness. As they say, "Shared state is the root of all evil". Search the phrase and you'll find way more information than I could ever write here. My point is, even systems engineers (who usually loves to deal with nasty stuff) are getting tired of shared state shenanigans and I think they are gonna be the ones that will convert much of existing infrastructure to immutable.

3. Moving stuff from runtime to compile time as much as possible. With ideas coming from fields like Type Theory and Abstract Algebra in general, now we can predict a reasonably wide domain of "bad" program behaviours before actually running it. The best part is, we can completely eliminate most of them in compile time by adding new rules which we can guarantee that won't lead to such "bad" states. Current implementation of memory management in Rust is a great example of this approach.

4. New approach to concurrency and parallelism. Although general-purpose operating systems are fairly good at performing various kind of tasks, fairly good is not good enough for specific applications. A classic example is concurrency and parallelism. Although OS-level active units like processes and threads are good for average OS-level tasks, they are too heavy and not flexible enough to be directly used in modern languages with very dynamic behaviour. So, more and more languages are coming up with their own solutions often in the form of language-level units that are very light and flexible alternative of OS-level threads. Also it's worth mentioning that this kind of approach often involves some sort of tricks to make resources like CPU time and memory pages more predictable, which the underlying OS developers wouldn't appreciate. After all, language developers want their program to perform better, where OS developers want the whole system to perform better.

5. Rise of multi-mode languages. Compilers can do hell lot of optimization for you, but it usually makes compiling process much longer. On the other hand, you only need such fine-tuned software in production environments. Unoptimized and rough version of the same software (which can be compiled much faster) is usually good enough for various kinds of testing and debugging purposes. So, why not give developers an option to chooses how much optimized result they want? Of course, both compiled and interpreted languages are doing a bunch of tricks to achieve something similar, but I think solutions in the next 10 years is gonna be more fundamental. Maybe, a language that is normally interpreted, but can compile the code to executable when it's ready for production.

We need a paradigm that is more predictable than Procedural Programming, more efficient than Object Oriented Programming and less fancy than Functional Programming.

Home is where you connect to wifi automatically
Home is where your internet works in 2G