HowProgrammingWorks - JavaScript and Node.js Programming

Сама логика предметной области имеет асинхронную природу. Ни какие балансировщики и гейтвеи, ни какие облака или FaaS не могут решить проблемы конкуррентного доступа к памяти, cpu, диску, системам ввода-вывода. Но писать доменный код в стиле параллельного программирования — это тупик, а асинхронное программирование не намного проще, тем более на #JavaScript под управлением #nodejs. Мои взгляд на этот вопрос будет в курсе, который готовлю, точной даты не знаю, но до нового года точно будет: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Async-2024.md

Как учить языки программирования? Несколько неочевидных подсказок: 🔵 Не нужно сразу стараться понять все, это как с человеческими языками, если концентрироваться на том, что вы не понимаете все на 100%, то обучение заблокировано, со временем пробелы будут закрываться, а после какого-то момента пазлы сложатся, 🟢 Нужно много читать и разбирать хорошего кода, основная деятельность программиста — это не написание, а чтение кода, это так не только во время обучения, но и в работе, 🟡 Нужно изучать плохой код, разбирать почему он плохой и исправлять, переписывать, улучшать, добиваться не скорости и применения сложных конструкций, а читаемости, простоты и понятности, 🔴 Важно делать ошибки, изобретать велосипеды, наступать на грабли, исправлять их и разбирать, в чем была проблема, конфликтовать и приходить к консенсусу, заходить в тупик и находить решение, это эффективнее всего делать в групповом проекте, объединяйтесь и работайте вместе. Тут мои новые лекции для начинающих и много заданий: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Beginners.md

⚡️ Ключевая проблема современности — это то, что люди пишут frontend или backend на NodeJS так и не освоив нормально асинхронное программирование. Его знание не наступает сразу после изучения синтаксиса JavaScript и TypeScript, надежность асинхронного кода невозможно полноценно проверить типами и очень сложно покрыть тестами. Нет ни одного нормального курса по асинхронщине, их вообще почти нет, но и мой курс из 26 лекций (по часу и более) — полное говно, он разросся и устарел. Все думают, что они с налету вот так освоили колбеки и таймеры, промисы и async/await и все... НЕТ, так не работает, асинхронное программирование намного сложнее и вам придется понимать про состояние гонки, блокировки и особенности отладки и даже проблемы стектрейсов, адаптеры контрактов и атомарные операции, ивент луп и микротаски... но асинхронное программирование, одновременно и намного проще, потому, что нужно писать ПРОСТОЙ асинхронный код, а не сопли на флагах и примесях, зонах и доменах, а писать асинхронщину просто и понятно ­— вообще ни кто не умеет. В продуктах так не пишут, там все на заплатках из миксинов и на if-ах, в оупенсорсе тоже так не пишут, там оверинженеринг процветает и люди выдумывают сложнейшие абстракции для простых вещей, просто потому, что могут. Я сделал по асинхронному программированию, наверно, наибольшее количество докладов, лекций, примеров и статей, но вот только 2 года назад начал писать хоть сколько-нибудь приличный асинхронный код. Да и сейчас сделать такой курс для меня огромный вызов и ответственность, который я бы с удовольствием разделил с коллегами, c Illya Klymov и Denys Otrishko, Dmytro Nechai и Alexey Orlenko, Alex Golikov и Alexey Migutsky если они согласятся сотрудничать в любом удобном виде, как критики или соавторы, как рецензенты или конкуренты. Вы, конечно, можете позвать и предложить других специалистов, которых я не назвал. Оглавление у меня уже готово, но я его покажу после нескольких итераций, а пока могу дать только ссылку на старый курс, как пример того, как делать не нужно 👉 https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Asynchronous.md

Чтобы писать на low-code нужно все то же, что и в обычном программировании, но это гораздо менее удобно. Условия и ветвление, циклы, структуры данных, работа с файлами, сетью, БД и прочее, никуда не деваются. Просто у вас не будет возможности: 🖕 писать юниттесты, 🖕 делать ревью кода, сравнивать код, 🖕 diff между коммитами, смотреть историю, версии кода, 🖕 модули, слои, компоненты - забудьте, 🖕 сложные схемы, более 100 блоков, Научитесь писать идеальный код с первого раза и чтобы его не нужно было поддерживать. Но есть и положительные моменты: ✅ красивая картинка продает, ✅ вы сможете списывать больше времени, ✅ бюджеты будут расти, Так же можете забыть про: 🚫 безопасность, 🚫 масштабируемость и надежность, 🚫 расширяемость и поддерживаемость, 🚫 предсказуемость сроков разработки. Удачи и терпения! С low-code они вам понадобятся.

Разработчик, помни, что ты вправе сам распоряжаться своей цифровой идентичностью и волен не соглашаться на предложения абьюзеров от менеджмента использовать, например, Jira или Confluence, если это нарушает твои личные границы. Сейчас они принуждают тебя к малому, а завтра заставят установить Скайп или Тимс на твоем компьютере. Сейчас ты допустишь легкий харасмент, но не успеешь и глазом моргнуть, как они начнут логать время, записывать снимки экрана, и вот их рука уже у тебя в трусах.

Как бы мог выглядеть идеальный web? Браузер с виртуальной машиной LISP и LISP сервер, обменивающиеся по сети S-выражениями. Естественно, S-выражения для описания UI. Полная однородность. Но на руках у нас только JS, который компилирует JS в JS и посылает JS другому JSу.

Почему большие коллективы менее эффективны в ИТ, все знают, что до 80% времени уходит на координацию. Но есть еще важный аспект: в крупных коллективах 20% времени уходит на три способа преодоления факапов, которые неизбежно в работе возникают: (1) построение оправданий, (2) обвинение коллег, и читаем в твиттере: https://twitter.com/tshemsedinov/status/1690966379485179905

Решение задачек про велосипедиста при помощи релятивистской механики — это как везде пихать ООП, а при помощи квантовой механики — это как пихать ФП. Люди, очнитесь, пишите простой процедурный код, зачем вам это чувство превосходства над массами?

На MDN есть статья, как писать на Node.js без фреймворков, с примерами кода из моего бесплатного курса. Но сейчас мы пошли еще дальше, как писать так, чтобы переезд с фреймворка на фреймворк занимал максимум пару часов. https://developer.mozilla.org/en-US/docs/Learn/Server-side/Node_server_without_framework

🖼 Если вы не читали группу всю неделю, то вот краткая выжимка, все цитаты за неделю: ⭐️ Менеджмент — это лженаука об управлении. А наука об управлении называется кибернетика. ⭐️ Парадигмы программирования, кроме процедурной — это пока еще так... игрушечки и эксперименты. Весь существенный софт написан процедурно. ⭐️ Если вы приличный человек, у вас успешный продукт, большая команда и кодовая база — то вам очень стыдно за код проекта. ⭐️ Секта антисектантов «осознанность» ⭐️ Появилось предположение, что Jira и прочий треш-софт придумали для того, чтобы оправдать найм непрограммистов и заполнить их рабочее время хоть чем-то работоспособным, кроме бесконечных созвонов. ⭐️ Чем заменить конфлюенс? Он прекрасно заменяется отсутствием конфлюенса. ⭐️ No-code advantages: no bugs, no problems, no tests needed, no git diff, no code review and fixes needed, perfect just after first release, no-code is compatible with serverless. ⭐️ Cloud naïve: PaaS — promise as a service ⭐️ Приходит Цекербрин к своим разработчикам и спрашивает: ну шо, когда уже наш фейсбук будет дописан окончательно? ⭐️ Любая достаточно развитая технология неотличима от Метархии.

Такими темпами JavaScript начнут преподавать в синагоге

⛔️ Как жить то? 👉 Сократить до минимума инструменты. 👉 Сократить интеграции между ними. 👉 Исключить дублирующие способы коммуникации. 👉 Исключить дублирующие инструменты и форматы документов. 👉 Вместо того, чтобы иметь 10-15 инструментов, можно иметь 3-4. 1️⃣ Современные Github и Gitlab умеют: тасктрекинг, багтрекинг, планирование проектов и времени, майлстоуны и канбан, база знаний проекта в виде discussions и wiki, все это органично связано, для всего можно делать шаблоны, так, что заведение issue может превратиться в заполнение формы, а отправка в запуск автоматизированного процесса трекинга задачи или бага вплоть до лендинга pull/merge реквестов, с использованием специальных тегов и ключевых слов в коммитах, ведение чеклистов для каждой операции, скриптов, запускаемых на машинах разработчиков и на CI, которые выполняют все, что менеджеры каменного века руками калапацали. 2️⃣ Мессенджер — это личный инструмент, вообще не подходит для продуктов и компаний. Мессенджеры — это место, где навсегда теряются знания, идеи, договоренности, потому, что лежат в виде соплей, размазанных по тредам, очень плохо перелинковываются и их неудобно включать в автоматизированные процессы, это место полнотекстового поиска, это превращает внутренние процессы компании в аналог слабосвязанного интернета, где нужен поисковик, вы наталкиваетесь на битые ссылки, что-то удалено, к чему-то залито в виде запароленного зипа в файловое хранилище, которое Вася перенес в облако и перегруппировал папки, а теперь у всех сообщений до прошлого года картинки не отображаются. 3️⃣ Надеюсь, все понимают принцип "инфраструктура как код", но проектная документация и все вспомогательные файлы (PNG, YAML, блок-схемы в JSON или XML и что угодно) тоже должны стать частью кодовой базы. Всевышний Аллах, безмерной милостью своей дал нам git и MD-файлы (markdown), которые могу автоматически форматироваться, собираться из частей, автоматически генерироваться и компилироваться в PDF и другие форматы. Более того, документация может автоматически публиковаться в HTML формате и выкатываться в виде удобного Web интерфейса, но за всем этим должен стоять единый источник правды - git репозиторий. ⚠️ Если у вас на проектах есть инструментарий подобный Jira, Slack, Trello, Confluence, Microsoft Teams и прочее дерьмо, подумайте, может оно вас больше отвлекает, чем дает что-то. Это вопрос привычки.

⭐️ Нода стала невыносимо сложной ☠️ вот что я понял, пока писал все эти вопросы для собеседований. Основная задача фреймворков - это снятие сложности. Так вот они не справляются с этим вообще. Если человек пишет на фреймворке, то он находится под давлением сложности NodeJS, сложности JavaScript, асинхронного программирования + еще сложность фреймворка + сложность предметной области. Это совершенно невыносимо, друзья. В тех компаниях, где я CTO, архитектор или эдвайзор, я пытаюсь распределить эту сложность хотя бы по разным людям, поэтому разделил роли прикладного (продуктового) и системного (платформенного) программиста, но этого мало. У них ве равно есть достаточно большое перекрытие сфер компетенции, да и сами компетенции, даже разделенные пополам, уже переросли когнитивные способности среднего программиста. Вы заметили, что во всех проектах появляется прослойка между нодой и доменом? Сначала оно легковесное, а за год оно становится совершенно неподъемным, а будучи смешанным с продуктом это просто смерть для компании. Можно делить платформу и продукт на разные репы, можно делить команды, роли, рабочее время разделять, но если не внедрена культура открытого и свободного программного обеспечения, то сложность захлестывает. Вот берите этот свой платформенный код, свои библиотеки и фреймворки и выкладывайте их в Open source, они все равно не являются конкурентным преимуществом бизнеса. Так нет же, вы ссыте, и не хотите заниматься их поддержкой, постоянным обновлением, багфиксами, тайпингами, тестами, доками, комьюнити, не хотите, чтобы кто-то пришел и обругал весь ваш платформенный код за то, что он ужасен, не хотите открытого сравнения с другими библиотеками и фреймворками. Это что касается бекенда на Nodejs. Кто там занимается фронтом, скажите, что там у вас со сложностью, что с культурой?

✨ К вопросам на собес по 🐢 #NodeJS 🚀 добавил еще 30 и их уже 100 там ✨ https://github.com/tshemsedinov/NodeJS-Interview-Questions

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