HowProgrammingWorks - JavaScript and Node.js Programming

— AI сможет создавать сложные кодовые базы с нуля // Дарио Амадей CEO Anthripic — Мы бы волновались, если бы он смог создавать простой код и не с нуля, а через рефакторинг, а так... Сложные и с нуля все могут.

— AI сможет создавать сложные кодовые базы с нуля // Дарио Амадей CEO Anthripic — Мы бы волновались, если бы он смог создавать простой код и не с нуля, а через рефакторинг, а так... Сложные и с нуля все могут.

— Почему вы не избавляетесь от сложности и технического долга? — Вы что, мы столько сил потратили на этот крутой код, он нам очень дорог!

💡 И немного о структурах данных: список со списками, это как массив с массивами, как кулек с кульками, как коробка с коробками: List<List<T>>

💡 Способы создания более сложных абстракций из простых в ООП и функциональном программировании сильно пересекаются: ∙ Наследование - для ООП тут все понятно, но что можно считать наследованием для функционального программирования? Для аналогичного наследованию эффекта можно использовать функции высшего порядка или частичное применение. ∙ Композиция - в ФП композиция везде, а вот в ООП обычно недооценена, реализуется через создание экземпляра одного класса внутри конструктора другого, композиция создает меньше зацепления и зависимости, проще тестировать, когнитивная нагрузка меньше. ∙ Агрегация - похожа на композицию, но ответственность за инстанцирование не на классе-владельце, т.е. создание экземпляров, вынесено в другие абстракции, а агрегирующий класс получает их уже готовые, чаще всего через конструктор и объединяет. ∙ Миксины - примешивать к готовым экземплярам ссылки на другие, это полный хаос, и три предыдущие способа гораздо предпочтительнее, но если нет никакого более красивого выхода, то можно применить, как временное решение, создающее техдолг. ∙ Ассоциация - иногда под этим термином понимают взаимодействие абстракций, это нормально, но иногда это значит внешнюю агрегацию, в худшем случае - через миксин, в лучшем - через сеттер, так что, это тоже создает зацепление и технический долг. ∙ Делегирование - это подвид композиции, когда интерфейс скомпозированного класса (внутреннего) полностью реализуется наружным классом, по сути это прямая замена наследования, без использования наследования и проблем, связанных с ним.

Functional programmers also can do nodejs

⭐️ Good and bad cases for TypeScript union types based on JavaScript V8 optimizations 👍 Good cases for union types: - Union of strings instead of enum: type Direction = 'north' | 'south' | 'east' | 'west'; - Union of numeric as status or result code: type StatusCode = 200 | 201 | 204 | 400 | 500; - Union with shared properties: type MailTarget = User | Company; (both with email) - Union with common method: type Thenable = Promise | Query; (both with then method) 👎 Bad cases for union types: - Polymorphic object shapes causing depots: type Something = User | Socket | string; - Requiring extensive "if"-logic and type checking: type Input = string | number | boolean; - Inconsistent return types: function getData(id: number): string | string[]; - Mixed primitives and objects: type Value = number | { value: number }; - Сontradictory members: type Person = { name: string; } | { name: number[] }; - Union types that include any: type FlexibleType = number | any; - Incompatible contracts: type Handler = (() => string) | ((event: Event, data: any) => void); 🎁 Empty value for primitive types and reference types: - Use null for empty reference types: Object, Function, Array, etc... - Use undefined for empty primitive types: string, number, boolean, bigint - Avoid mixing symbols with other types in unions

Начинающий программист совершенно уверен в том, как все должно быть, но не знает как и шагу ступить в конкретной ситуации. А опытный программист не уверен в том, как все на самом деле, но точно знает, как действовать в конкретной ситуации. Концепции, парадигмы, паттерны и принципы, построены как мифы и верования. И самое парадоксальное в мифе, что он работает, дает хорошие результаты в ежедневной практике. Не нужно думать о нем, как о чем-то мистическом, выдуманном, отвлеченном. Если программист избавится от мифологического сознания, например перестанет верить в микросервисы, в nodejsоднопоточный, в скалярные типы данных, перестанет писать на примесях и мидлварах, то картина мира рассыпается и он не может ничего написать. Чтобы опять начать что-то создавать, нужно построить другой миф. Только ощущение, что у тебя сложилась картина мира, позволяет перейти от теории к практике. Но любая картина мира состоит из разрозненных фактов, которые переклеены мифом, иначе, бы мы утонули в зазорах между знаниями, как в пустотах между электронами и атомами. Без мифа мир страшен, непредсказуем и неуправляем. Опытный программист просто имеет несколько мифов в голове и может между ними переходить, некоторые могут даже конструировать свои, и такое конструирование может быть только интуитивное, если его начать логически строить, то никто не поверит. В мифе должны быть нестыковки, странности, даже противоречия, вот это заходит в голову идеально. Это инструмент, который позволяет действовать эффективно, скрывать сложность, давать целостную картину мира, но не слишком идеальную, чтобы было место для развития.

«выкладывайте код из вашей повседневной разработки в сторис, это легко и весело, и через 24 часа они исчезнут»

⚠️ Завтра первый день онбординга на Patterns 2024. Это нулевая неделя, формируются группы и назначаются менторы. Процесс оказался не таким простым организационно. Всем, кто зарегистрировался - прошу спокойно подождать до вечера и если вам на почту не придет приглашение, то утром обратиться в нашу поддержку, там отдельные люди занимаются вопросами платежей, рассрочкой, потерянными контактами (часть людей везде указывает разные почты и телефоны, вводят "Юра" или "EA 00 00 FF FF" в поле фамилии и невозможно понять, кто это). ∙ Поддержка по платежам: https://t.me/patterns2024 или на почту javascript.patterns.2024@gmail.com ∙ Кто зарегистрировался но не оплатил, то платить тут https://nodeua.com/Patterns-2024-buy.html ∙ Кто оплатил, но не заполнил форму, это тут: https://forms.gle/wuJ3nvSeF2apgUESA ∙ Кто и зарегистрировлся и оплатил, но не полял куда попал, то можно посмотреть описание тренинговой программы на трех языках тут https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024.md ∙ Курсы по ноде и по асинхронному программированию тут: https://www.patreon.com/tshemsedinov Пишу это потому, что есть люди, которые пишут, что хотели попасть на курс по ноде и уже где-то оплатили, а оказалось, что они на паттерны попали.

Проблема сложности, которую решают микросервисы, на самом деле решается проектированием структуры кода на среднем уровне, т.е. люди от функций и классов хотят перескочить сразу к архитектуре, минуя модули, слои, подсистемы. Если код хорошо структурирован на среднем уровне благодаря: - системам модульности, - внедрению зависимостей и инверсии управления, - архитектурным границам и слоям, - декомпозиции абстракций, - separation of concerns, - information expert, - контрактному программированию, - управлению, сокрытию и изоляции сложности, - разделению прикладного и системного кода, то такое приложение можно в течении нескольких часов собрать в 2, 3, 5, 105 инстансов, заменив взаимодействие между их структурными компонентами на RPC и трансляцию событий. Так, что модули и подсистемы знать не будут, что они запущены не в одном процессе. А если код «рыхлый», то его и микросервисом не изолировать, у такого сервиса будет большой внешний трафик, потому, что зацепление на чужие данные и чужую логику высоки. Так что, «распиливание» это только распиливание бюджета команд и бюджета на инфраструктуру. Обойти вопрос хаоса на среднем уровне при помощи чуда не выйдет. Чтобы построить Application архитектуру, нужна качественная структура, а чтобы перейти к Solution и Enterprise архитектуре, нужна качественная Application архитектура. Попытки перескочить от функции, цикла и массива к Solution архитектуре приводят к появлению монстров типа облачных функций, микролитов, моносервисов и скоро мы увидим Variable as a Service, а потом гору этих абстракций, вываленных на уровень Solution, не сгруппированных и не изолированных в структурные единицы управления сложностью. Чуда не будет, ни кто не решит за нас вопрос перехода от отдельного кирпича к небоскребу, нужны промежуточные структурные единицы.

🧩 Тарифные планы тренинга с наставниками Patterns 2024 ∙ Minimal: обучение в общей группе без наставника, но с групповыми семинарами ∙ Standard: обучение с наставником в небольших группах (10 человек) ∙ Professional: обучение с наставником, индивидуально и в группах, дополнительные материалы ∙ Exclusive: персонализированный учебный трек с автором курса и приглашенными экспертами 👉 Подробности: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md Формат тренинга 🗓 12 недель (3 месяца) + онбординг (1 неделя) + секретный модуль 👍 Доступ к материалам курса дается навсегда 🕑 Каждую неделю обязательно: 1 час лекций + 2 часа семинаров + 2 часа самостоятельной работы 🥋 Тренировки и групповая работа с наставниками, а не только смотрение видосов и чтение 🙋‍♂️ По желанию: для глубокого погружения +3 часа дополнительных материалов на старших тарифах 🏅 По завершению курса Вы получаете сертификат ⚠️ Входные требования: базовый JavaScript + рекомендуется опыт практического программирования 🙅 Для кого не подойдет: не для начинающих, бесплатные материалы для начинающих ищите у Тимура 💳 Рассрочка: помесячная оплата для всех тарифов кроме минимального 🗺 После курса участие в комьюнити выпускников, где уже тысячи людей по всему миру 👉 Купить: https://nodeua.com/Patterns-2024-buy.html