HowProgrammingWorks - JavaScript and Node.js Programming
6.2K subscribers
254 photos
5 videos
1 file
656 links
Программная инженерия и JavaScript сообщества Метархия.

Ссылки на митапы, группы и каналы сообщества https://github.com/HowProgrammingWorks/Index/blob/master/Links.md
Download Telegram
Forwarded from Metaeducation
Такими темпами JavaScript начнут преподавать в синагоге
🖼 Если вы не читали группы всю неделю, то вот краткая выжимка, все цитаты за неделю:

⭐️ Менеджмент — это лженаука об управлении. А наука об управлении называется кибернетика.

⭐️ Парадигмы программирования, кроме процедурной — это пока еще так... игрушечки и эксперименты. Весь существенный софт написан процедурно.

⭐️ Если вы приличный человек, у вас успешный продукт, большая команда и кодовая база — то вам очень стыдно за код проекта.

⭐️ Секта антисектантов «осознанность»

⭐️ Появилось предположение, что 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

⭐️ Приходит Цекербрин к своим разработчикам и спрашивает: ну шо, когда уже наш фейсбук будет дописан окончательно?

⭐️ Любая достаточно развитая технология неотличима от Метархии.
Please open Telegram to view this post
VIEW IN TELEGRAM
На MDN есть статья, как писать на Node.js без фреймворков, с примерами кода из моего бесплатного курса. Но сейчас мы пошли еще дальше, как писать так, чтобы переезд с фреймворка на фреймворк занимал максимум пару часов. https://developer.mozilla.org/en-US/docs/Learn/Server-side/Node_server_without_framework
Решение задачек про велосипедиста при помощи релятивистской механики — это как везде пихать ООП, а при помощи квантовой механики — это как пихать ФП. Люди, очнитесь, пишите простой процедурный код, зачем вам это чувство превосходства над массами?
Почему большие коллективы менее эффективны в ИТ, все знают, что до 80% времени уходит на координацию. Но есть еще важный аспект: в крупных коллективах 20% времени уходит на три способа преодоления факапов, которые неизбежно в работе возникают: (1) построение оправданий, (2) обвинение коллег, и читаем в твиттере: https://twitter.com/tshemsedinov/status/1690966379485179905
Как бы мог выглядеть идеальный web? Браузер с виртуальной машиной LISP и LISP сервер, обменивающиеся по сети S-выражениями. Естественно, S-выражения для описания UI. Полная однородность. Но на руках у нас только JS, который компилирует JS в JS и посылает JS другому JSу.
Разработчик, помни, что ты вправе сам распоряжаться своей цифровой идентичностью и волен не соглашаться на предложения абьюзеров от менеджмента использовать, например, Jira или Confluence, если это нарушает твои личные границы. Сейчас они принуждают тебя к малому, а завтра заставят установить Скайп или Тимс на твоем компьютере. Сейчас ты допустишь легкий харасмент, но не успеешь и глазом моргнуть, как они начнут логать время, записывать снимки экрана, и вот их рука уже у тебя в трусах.
Чтобы писать на low-code нужно все то же, что и в обычном программировании, но это гораздо менее удобно. Условия и ветвление, циклы, структуры данных, работа с файлами, сетью, БД и прочее, никуда не деваются. Просто у вас не будет возможности:
🖕 писать юниттесты,
🖕 делать ревью кода, сравнивать код,
🖕 diff между коммитами, смотреть историю, версии кода,
🖕 модули, слои, компоненты - забудьте,
🖕 сложные схемы, более 100 блоков,
Научитесь писать идеальный код с первого раза и чтобы его не нужно было поддерживать.
Но есть и положительные моменты:
красивая картинка продает,
вы сможете списывать больше времени,
бюджеты будут расти,
Так же можете забыть про:
🚫 безопасность,
🚫 масштабируемость и надежность,
🚫 расширяемость и поддерживаемость,
🚫 предсказуемость сроков разработки.
Удачи и терпения! С low-code они вам понадобятся.
⚡️ Ключевая проблема современности — это то, что люди пишут 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
Как учить языки программирования? Несколько неочевидных подсказок:

🔵 Не нужно сразу стараться понять все, это как с человеческими языками, если концентрироваться на том, что вы не понимаете все на 100%, то обучение заблокировано, со временем пробелы будут закрываться, а после какого-то момента пазлы сложатся,
🟢 Нужно много читать и разбирать хорошего кода, основная деятельность программиста — это не написание, а чтение кода, это так не только во время обучения, но и в работе,
🟡 Нужно изучать плохой код, разбирать почему он плохой и исправлять, переписывать, улучшать, добиваться не скорости и применения сложных конструкций, а читаемости, простоты и понятности,
🔴 Важно делать ошибки, изобретать велосипеды, наступать на грабли, исправлять их и разбирать, в чем была проблема, конфликтовать и приходить к консенсусу, заходить в тупик и находить решение, это эффективнее всего делать в групповом проекте, объединяйтесь и работайте вместе.

Тут мои новые лекции для начинающих и много заданий: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Beginners.md
Forwarded from Asynchronous Programming
Сама логика предметной области имеет асинхронную природу. Ни какие балансировщики и гейтвеи, ни какие облака или FaaS не могут решить проблемы конкуррентного доступа к памяти, cpu, диску, системам ввода-вывода. Но писать доменный код в стиле параллельного программирования — это тупик, а асинхронное программирование не намного проще, тем более на #JavaScript под управлением #nodejs. Мои взгляд на этот вопрос будет в курсе, который готовлю, точной даты не знаю, но до нового года точно будет: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Async-2024.md
⭐️ Тут сведены идеи применения AI, точнее LLMок в разработке программного обеспечения. Что они делают хорошо 🟢, что удовлетворительно 🟧, а что вообще плохо 🛑
🟢 Анализ больших объемов данных, которые человеку сложно внимательно обработать
∙ логов и стектрейсов
∙ memory dumps
∙ dependency trees
∙ git blame
🟢 Портирование:
∙ с одной версии фреймворка или библиотеки на другую
∙ с одного языка на другой
∙ с одной СУБД на другую
∙ с одной OS на другую или поддержка нескольких
🟢 Боты и тулинг для автоматизации обработки кодовой базы и репозиториев:
∙ применение стиля
∙ применение чеклиста изменений
∙ поиск уязвимостей в кодовой базе
∙ маркировка commits, pull requests, issues
∙ расстановка тегов по коммитам и т.д.
∙ автоматизация закрытия тасков, майлстоунов
∙ поиск дубликатов кода, тасков, или перелинковка связанных
∙ аудит объемов работы, качества, сбор статистики
∙ предложения для рефакторинга
∙ поддержание консистентности кодовой базы и стиля
∙ создание спеки стиля кода по примерам кода или кодовой базе проекта
∙ предложение метрик для оценки кода и вычисление этих метрик
🟢 Написание текстов:
∙ подготовка CHANGELOG, HOW TO, Q&A
∙ генерация документации по коду
∙ реверс-инжиниринг кода в ТЗ
∙ поиск отличий между ТЗ, кодом, доками
∙ преобразование между форматами данных, например json, csv, pdf, sql, txt
🟢 Управление проектами
∙ оценка трудоемкости разработки, времени и денег
∙ оценка возможности распараллеливания разработки
∙ поиск слабых мест и выявление проблем в сметах, планах, ТЗ
∙ предложения по оптимизации бизнес-процессов
∙ сбор данных для подготовки принятия решений
🟢 Программирование
∙ алгоритмические задачи, подбор и реализация алгоритмов
∙ портирование, перевод и транспиляция между языками программирования
∙ преобразование между class и prototype в JavaScript
∙ оптимизация по заданному критерию: cpu, ram, i/o, lines, читаемость, сложность, etc.
∙ объяснение кода
∙ генерация примеров использования библиотек или абстракций
∙ ревью пул реквестов
∙ генерация юниттестов, системных тестов
∙ генерация конфигураций
∙ настройка CI/CD
∙ генерация SQL запросов
∙ генерация API, CRUD, формочек
∙ генерация моделей, структур, DTO, схем данных, классов, jsdoc
∙ преобразование моделей между разными синтаксисами
∙ синхронизаций структуры базы данных, схем, моделей, форочек
∙ генерация тайпингов и заголовочных файлов как .h, .d.ts
∙ подготовка контрактов и описание интерфейсов для интеграции систем
∙ генерация парсеров, конвертеров, по примерам входных и выходных форматов данных
∙ генерация валидаторов данных и валидаторов контрактов
🟧 Задачи, которые LLMки делают, но не всегда качественно и с проблемами
∙ терпимо конвертирует код между парадигмами: ООП, процедурное и структурное программирование
∙ гораздо хуже конвертирует между ООП и ФП
∙ асинхронное программирование и задачи с доступом к состоянию из разных мест
∙ олимпиадное программирование
∙ подготовка шаблонов и примеров приложений/проектов
∙ выбор зависимостей
∙ выбор СУБД, языков программирования, платформ, тулинга
∙ концептуальный код, демонстрирующий идею и делающий ее понятнее для многих
🛑 Что плохо решается при помощи LLMок
∙ системное программирование
∙ платформенный код, код библиотек, фреймворков
∙ новые и прорывные технологические решения, которые негде подсмотреть
∙ большинство новых нетипичных задач, когда в интернете мало примеров кода
∙ архитектура систем и структура приложений, даже при наличии множества примеров
😜 Есть такой эффект, и я иногда чувствую вину за его распространение: человек только осваивает язык и платформу, но попадает на сложную лекцию о том, как все устроено внутри, о недокументированных функциях, оптимизациях, высоконагруженных и распределенных системах, многопоточности, сборке мусора, метапрограммировании, ивентлупе и т.д. и вот ему дают задачу (или он сам себе ее ставит) например: «сделать апи для получения с сервера списка городов» и тут он вспоминает про асинхронные генераторы, бекпрешер в стримах, про инверсию управления и начинается... нужно все сделать по науке, чтоб миллион пользователей пришло и что будет, если каждый 10 раз в секунду будет выкачивать список, в котором сотни тысяч записей, а может быть давайте не в JSON слать, а придумаем для этого бинарный протокол и сэкономим на кавычках и запятых, будем строки разделать байтом FF, и обязательно предусмотреть отмену получения списка и докачку, если соединение разорвалось с того же места и чтоб кеширование работало, но была возможность принудительно кеш обновлять... А если справочник меняется, то нужно вебсокетами присылать изменения, нужно придумать в каком формате, и таймаут держать в памяти, что если докачка не началась в течении 5 минут, то уже не начнется, а если соединение восстановлено, но мы подключились к другому процессу или потоку, а если сервер перегрузился нужно же... и это бесконечно, так складывание двух чисел можно защищать от влияния космических лучей... я уже не говорю про микротесты и нагрузочные тесты, которые непременно нужно нужно гонять пару часов. Ну... все это... конечно способствует освоению платформы, это интересно и через пару лет может дать полезные результаты и я не хочу отговаривать от экспериментов, но признайтесь себе, сколько будет пользователей, данных и интенсивности через год, два, три, прикиньте грубо, ну на 2 можно умножить и дать себе отчёт в действительных целях своего R&D
Please open Telegram to view this post
VIEW IN TELEGRAM
🏋️ Что кодворс что литкод позволяют хорошо потренироваться в тех задачах, которых никогда не будет на робочих проектах.