Евгений Паромов

Самое важное чему я научился за год Недавно совершенно случайно наткнулся на это видео https://www.youtube.com/watch?v=V2EyKJF403M Я, вообще, уважаю пожилых людей и прислушиваюсь к тому, что они говорят. Особенно тех, кто посвятил себя изысканиям и развитию. Но большую часть видео я ловил кринжа и хотел уже закрывать. Но, в какой-то момент меня зацепила одна фраза. "Самое главное – научиться чувствовать циклическое время" В видео об этом говорится, как об ощущении пульсации. Ощущении годовых, месячных, недельных, дневных циклов. Как меняется состояние и энергия. И эта фраза для меня стала апогеем. Стала ключевой точкой моих поисков стабильности и предсказуемости. Я всю жизнь винил себя за перепады энергии. За то, что не могу быть постоянным, стабильным. Чем больше искал стабильности, тем меньше энергии у меня было в принципе. И теперь понятно почему: Сама суть жизни – пульсация. Вдох выдох. День ночь. Зима Лето Движение с постоянной скоростью — смерть. Чтобы быть счастливым и предсказуемым не нужно пытаться себя выровнять. Это путь к депрессии и самоистязаниям. Нужно оседлать эти циклы. Не планировать большие проекты зимой. Не записывать видео по ночам. Давать себе паузы после больших запусков, и так далее. Советы настоящего капитана. Но как часто мы пытаемся этому перечить из-за того, что "надо" Чем больше во мне жизни, тем больше перепады энергии. Предсказуемость — умение прогнозировать эти перепады. А стабильность к чёрту!

Все видео по разработке платформы готовы https://micro-courses.ru/course/micro-courses-dev Вообще, для меня эта серия видео – очередной урок. Нужно тщательнее расчитывать объёмы тех вещей, за которые берёшься. И особенно тех вещей, которые объявляешь публично. Изначальный план был: за 1 месяц записать всю серию. А в результате делал это почти 5 месяцев 😅 При категорическом сокращении изначальной задумки, всего получилось около 30 часов видео Это почти рабочая неделя... В общем, очередной урок от жизни Пора бы научиться 🥲

Накидайте бустов, пожалуйста https://t.me/boost/cleanfrontend Очень хочу попробовать сторисы вам пулять. Я вообще любитель за жизнь позатирать и сторисы – хороший формат. Но, к сожалению, телега сделала из сторис какой-то странный момент. В любом случае, кому не сложно – накидайте бустов. Буду очень признателен 🤗

Всем привет! Монтаж многочасовых видосов по платформе чуть затянулся. Но 6 и 7 уроки я уже выпустил ✔️ https://micro-courses.ru/course/micro-courses-dev Чуть изменил формат видео. Благодаря этому, они готовы уже сейчас, а не через месяц. Надеюсь, вам будет полезно)

Ребят, ребят, ребят. Я, похоже, сделал это 😄 История. У нас на проекте монорепа. Несколько приложений, которые переиспользуют большие куски логики. И чем дальше в лес, тем большие куски нужно переиспользовать. И вылезает типичная проблема. Как изменять поведение общего кода, в зависимости от приложения. Например ui кит, конфигурацию, api сервис и тому подобное Есть типичное решение – инверсия зависимостей. Когда модуль определяет типы, которые должно реализовать приложение. И использует эти типы в коде

//shared module
type Deps = {
  apiService: Api
}

const createModule = (deps: Deps) => {
    const someFunction = () => {
       deps.apiService.getUser();
    }
   return {someFunction}
}
// application code
createModule({ apiService: new AppApi() }).someFunction()

И это хорошо работает для небольших модулей. Но, представьте, у нас не 1 файл, а тысячи. Большие развесистые зависимости. В этот момент начинается очень много проблем с разрешением этих зависимостей и раскладыванием их в нужных местах Как всегда в подобных ситуациях, я начал смотреть в сторону Dependency Injection контейнеров. Перепробовав всё, что есть на рынке, понял, что всё сделано дико не удобно. Устаревшие декораторы, классы, ключи, всё плохо код сплитится и чанкуется. Короче беда бедой. Реально нормальный туллинг для инверсии зависимостей в typescript это на данный момент не решённая проблема. Я много лет пытался придумать решение этой проблемы, но всегда получалась какая то дичь. Понимая, что в общем виде эта задача нормально не решается, попробовал сделать узкое решение, для задачи абстрактного модуля. И к вечеру я просто выпал. Совершенно того не желая, я походу сделал идеальный DI. Вдохновившись Reader монадой + добавив возможность прямого взаимодействия модулей для удобства получилось: - Сделать полноценный DI с возможностью как связывать модули по интерфейсу, так и делать прямое взаимодействие но с авто резолвом зависимостей - Он получился супер маленьким (один файл) - Никаких классов и декораторов. Просто функции - Всё строго типизировано - Кодсплитится - Не много бойлерплейта Последнее очень важно. Во всех реализациях без декораторов много бойлерплейта. Это то, что я никак не мог побороть эти 3 года. Но, похоже, что получилось. (Готового для показа кода нет, чуть подождите) Понятное дело, что нужно ещё тестировать много, и попробовать в разных кейсах. Но, повторюсь: Я уже 3 года пытаюсь сделать нормальный DI. Я знаю все проблемы и возможные подводные камни наизусть. То, что получается, выглядит слишком хорошо. В общем, ребят, сегодня все мои планы немного меняются. В ближайшее время сделаю видос на youtube c демонстрацией и npm пакет. Всем благ, желаю вам инженирить, да не оверинженирить ✨

И вот вам немного интересных мыслей из отпуска, которыми очень хочется поделиться: Информация – ключ к обобщению 🗝 Я вам люблю рассказывать всякие архитектурные принципы, лучшие практики. GRASP, GOF, чистая архитектура, DDD, и вот с курсом по Redux добавился Flux. И, знаете, есть стойкое ощущение, что всё это говорит об одном. Как из притчи про слепцов и слона. Приведу пример) Есть принцип SRP из SOLID. Он говорит, что один модуль программы должен изменяться только по причине одного актора. И я слышал размышление, что это правило – есть практический совет, как получить low coupling и high-cochesion. Так как потребности актора затрагивают только определённый набор модулей, и удовлетворение этого актора является задачей этого модуля. Что и определяет high cochesion. А взаимодействие акторов более ограничено, поэтому мы получаем low coupling Если взять все архитектурные принципы и рядом их поставить начиная с DRY YAGNY, продолжая SOLIG GRASP, и заканчивая DDD Clean Architecture FSD MVC MVVM Есть устойчивое ощущение, что они говорят вообще об одном и том же, просто на разном уровне, и с разных сторон Как будто нам не хватает какой то "Таблицы Менделеева", которая бы соединила все эти практики в единую систему, которая зиждилась бы на более абстрактных понятиях. И таким абстрактным понятием может быть Информация При подготовке к курсу по Redux, мне всё казалось. что мои размышление ватные. Как будто они подвешаны в воздухе и не имеют глубины. Я начал эту глубину искать. В результате потратил часов 25 в копании понятий Состояние, Кэш, Стейт менеджер. И самым базовым понятием, на котором всё строится, стало понятие Информация. Не просто так наша отрасль называется IT. Единственное, чем мы занимается — представляем, обрабатываем, передаём информацию. Но почему то при рассуждении о качестве кода, мы вообще не пользуемся этим термином. Хотя если его добавить, всё начинает сиять новыми красками. Вот несколько интересных тезисов 👇🏻 1. Любой код — информация по работе с информацией 2. DRY — должен быть один источник истины. В сущности мы не должны допускать копий информации. Похожий код может нести разную информацию. Разный код может быть копией информации 3. Копирование информации допустимо, если это кэш (Зависимая информация, которая не меняется отдельно от источника истины) 4. Приложения работают не с объектами, а с представлением информации об объектах (данными) 5. Разделение ответственности — это ограничение с какой частью информации об объекте будет работать модуль программы, и на каком уровне абстракции 6. Архитектура — это стратегия разделение информации по модулям, уровням абстракции. И механизмы обмена информацией 7. Любимая фраза начинающих архитекторов: Модуль А ничего не знает о модуле B — целиком про информацию И это только лежащие на поверхности тезисы. Буду продолжать копать, может сформулирую законченную модель на

Первая новость ⬇️ За отпуск почти дозаписал серию видео про платформу. Специально для тех немногих, кому это важно. И чтобы прервать череду невыполненных обязательств Для тех, кто осилит, будет мега польза. Но осилить это будет не просто 😁 В планах выложить всё сразу на платформу на следующей неделе

Всем привет! Я возвращаюсь с отпуска. Хорошо отдохнул. Чуть потолстел, чуть загорел) Как всегда привёз тонны идей, энергии и планов. Принял ряд важнейших решений. Со временем всё расскажу, но одним словом: это будет судьбоносный для меня квадриместр

Что будет дальше 1. Я пойду в отпуск) Как обычно, в деревню к своим родителям и оттуда в сочи на пару дней. Я хорошо потрудился и заслуживаю отдохнуть. 2. В отпуске планирую записать много видео по разработке платформы. Совсем без программирования я не умею. Буду делать самое приятное и понятное. Хочу максимально упростить формат, чтобы ускорить процесс и закрыть эту тему поскорее 3. После отпуска сразу начну делать курс по основам Redux. Он будет бесплатный, выложу его сразу и на youtube, и на свою платформу. 4. Дальше пойду в самую актуальную для меня тему: Redux-saga. Я действительно очень полюбил этот инструмент. Инструмент уникальный по своим характеристикам и возможностям. По факту, он один может стать причиной взять Redux в проект, так как позволяет "Императивно" (Почему это хорошо – будет в курсе) и понятно описывать дико сложные асинхронные процессы. А самое главное, убрать всю логику на useEffect из проекта. Удобных инструментов для такого 3: redux-saga, redux-observable, reatom. Redux-saga – самый популярный и понятный 5. Сделаю курс по интеграции react-query и redux. Возможно, на основе Redux-saga, возможно, без него. Вообще, для меня осознание механизма интеграции redux с react-query очень сильно улучшил позиции Redux в моих глазах. Я смог разделить кэш и данные, и сделать последовательную и удобную интеграцию. В результате совместил лучшее из двух миров Дальше уже не загадываю. Не знаю, как быстро будут выходить эти курсы, и какой будет на них спрос. И тут вы уже можете повлиять на то, что будет дальше. Пишите в комментах, что для вас более актуально. Не ограничивайтеь Redux, мне важно любое ваше мнение ☺️

Представляю вашему вниманию курc: "Архитектура Redux" Залил вчера все уроки на платформу, и теперь он доступен для покупки) https://micro-courses.ru/course/redux-architecture Итак, что будет в курсе и для кого он подходит ⬇️ Этот курс – первый шаг для углубления в теме стейт менеджмента и Архитектуры Redux. Он нужен, чтобы осознать: ✔️ Что такое Redux ✔️ Какая у него архитектура ✔️ Какие это даёт преимущества ✔️ Какие недостатки ✔️ Где его можно использовать ✔️ Где не надо Более того, цель курса – показать вам, как использовать Redux эффективно. Я дам прям готовую Архитектуру, которая строится на Архитектуре Redux, и которая отвечает на конкретные вопросы: - Что такое экшон? - Что должно быть в редьюсере? - Что должно быть в селекторах? - Где писать бизнес логику? В результате вы получите готовый архитектурный шаблон, который можно сразу использовать в подходящих для Redux ситуациях. Что важно: мы рассмотрим эту архитектуру в 2х вариациях: 1. Идеальной (чтобы осознать концепции) 2. Адаптированной к реальности (чтобы раскрыть подробности и предложить трейдофы) В конце будет домашнее задание для закрепления адаптированной к реальности версии архитектуры. В общем, курс получился сбалансированным. Тут будет как копание в понятиях Информация, Данные, Кэш, Состояние. Так и конкретные практические советы по код сплитингу и разделению стора на независимые модули. Если вы работаете с Redux – курс для вас. 🤑 Цена вопроса сейчас: 4000₽ Но уже в пятницу я подниму её до 5000₽ Но, важно: если вы вообще не знакомы с Redux и Rtk, курс вам не подойдёт. Дождитесь моего следующего курса, в котором я как раз дам всю необходимую базу для освоения Redux с нуля (он будет бесплатный).

Гуляю вчера вечером, кофий попиваю. Заметил дядю, который играет на гитаре Настроение хорошее, хоть и лужи под ногами. Давно мечтал петь на улице иногда. Не за деньги, а так. Для души. Прошлым летом купил себе гитару с подключением, комбарь на батарейках, микрофон. Но так и не смог решиться... А сегодня такое настроение хорошее было. Никуда не тороплюсь... И песни хорошие... В общем, спел 😄 Мне даже пару соточек кинули женщины с детьми. Возможно, отозвалось моё проникновенное исполнение "Сансары" Басты. Представлял мою любимую дочь в этот момент. (Да и пою я не плохо – в школе и универе своя рок группа была) Когда закончил – эйфория. Как же классно разрушать внутренние границы. Как же классно жить свою лучшую и единственную жизнь без страха P.S Фотка реально сегодняшняя. Архангельск такой Архангельск

Вчера я записал последний, 22 урок, первого курса из серии про redux – "Архитектура Redux" 😊 И выйдет он в ближайшие дни. Я просто тащусь от того, что получается. Вообще, это первый раз, когда я прям доволен тем, что сделал. – Когда я делал курс по React на youtube, был ограничен челленджем и форматом гига курса на 10к уроков –Когда делал курс по FSD, я сам себя поставил в рамки расписания выхода уроков и не смог должное время уделить качеству подачи материала. Сделать его доступным, ну или хотя бы разделить по уровню – Когда делал zod, я вообще уебался перед этим, запуская платформу Всё это было из-за определённых психологических проблем. Теперь я их проработал и просто смог сделать курс без дедлайнов, гонок и всяких загонов. По моему скромному мнению, получается просто офигенно 😁 И на то есть причины, на самом деле. Я полностью изменил структуру подачи контента, опираясь на 2 концепции. 1. "Цикл контакта" 🌀 Большая часть уроков построена в соответствии с концепцией "Цикл контакта", которую я тыранул у гештальт психологов. Если вкратце: у каждого урока есть ограниченный набор важных смыслов, и я провожу вас по 4 стадиям контакта с этими смыслами. В результате уроки получились более короткими, а информация усваивается просто офигенно 2. Долой "вату" 🔥 Я постарался убрать "Вату" из уроков. Что я называю ватой? Это та информация, которая звучит не убидительно. Которая подана незнакомыми терминами. Фразами, которые вообще не вызывают ассоциации и отсылки к опыту. Не подкреплены доказательствами. Пример ваты – это всякие слайды с определениями из универа, которые звучат как мантра, без серьёзного опыта взаимодействия с темой. Все концепции я постарался либо раскрыть через ассоциации и опыт, либо тщательно раскрыл все составные части определения. Например, чтобы разобраться, что такое стейт менеджер, мы разбираемся, что такое информация, данные, состояние, кэш и так далее. Вообще, я знатно тут потрудился над подачей и смыслами. Первые уроки перезаписывал по многу раз. Менял структуру, смыслы, последовательность повествования. Пока не почуствовал, что там минимум ваты. К сожалению, не всё получилось так раскрыть, но самые важные вещи в рамках темы "Архитектуры стейт менеджера" я прям тщательно проработал. Не хватает мне ещё ~10 микро курсов, которые хорошо раскрывают смежные концепции. Но это как раз то, почему я держусь за идею микро курсов. Чтобы я не обязан был давать в каждом курсе одни и те же концепции, а мог ссылаться на уже готовый качественный материал. Завтра расскажу вам, что будет в курсе, и что планирую делать после него 🙂

Я готовлю серию курсов по redux Анализируя весь свой опыт различных технологий, Redux остаётся самой непонятой из всех. Став мейнстримом, он потерял все концепции которые изначально нёс, в результате оказался жутко недопонятым. Из-за этого критикуемым и убивающим проекты Его используют где надо и где не надо. Но даже где надо используют не правильно. Я давненько обещал рассказать вам, как эффективно использовать Redux. И теперь, когда для меня это снова очень актуальная и животрепещущая тема, я решил записать серию курсов про него. Эти курсы будут выстроены в Иерархию. Благодаря этому, я смогу рассказывать темы более качественно, а вы сможете выбрать именно то, что нужно. Более того, Фундаментальный курс по RTK я собираюсь сделать бесплатным. Вообще, у меня есть идея, чтобы все курсы, которые необходимы для трудоустройства, были бесплатными. А уже за продвинутые, точечные курсы работающим разработчикам заплатить не сложно И как раз этим я занимаюсь последние 3 недели. В этот раз подход к курсам, которые я собираюсь делать, категорически отличается. Наконец, у меня не горит жопа, а я спокойно и с удовольствием делаю лучшее, что могу выдать. Но об этом подробнее завтра 🙂

Фу, переобулся Я вам рассказывал, что уже несколько месяцев на новом проекте работаю. Это группа проектов с ежедневной аудиторией больше 1млн человек. Тут я обычный senior разработчик, и не могу так влиять на процессы, как обычно И, короче, тут Redux) Думаю, вы знаете моё отношение к редаксу... И, знаете, мне зашло 😄 Дело в том, что он оправдан. 1. Здесь есть сложная клиентская бизнес логика маркетингового толка (Показ всевозможных баннеров на всякие условия). Это жутко сложная штука. 2. Сложные анимации, которые должны быть связаны с бизнес flow (Пока анимация не завершится, не можем продолжить) 3. Есть потребность в управлении загрузкой приложения ещё до того, как загрузился React чанк 4. Очень сложный флоу инициализации приложения. Который ещё нужно оптимизировать для улучшения tti И здесь должны были сиять redux + redux-saga, как инструменты созданные именно для этого. Для описания сложной клиентской бизнес логики. Но использовались они совершенно не верно... Вместо того, чтобы описывать полноценные бизнесовые флоу, redux саги использовались как фитчилки данных. А вся логика была размазана по десяткам useEffect Каждый раз, когда нужно было сделать редирект, поток данных нырял из саг в useEffect и обратно 🤢 Короче, всё смешалось. redux бездарно использовался как react-query, а useEffect использовался повсеместно при живой redux-saga Сначала я выпал в осадок от очередного разочарования от редакса. Но сразу понял, что не Redux виноват. redux-saga – единственный актуальный инструмент, который здесь идеально подходит. Но вообще нигде нет информации, как правильно использовать Redux Redux-saga rtk Осознав это, я расчехлил все свои знания об архитектуре и наработки по выпиливанию логики из useEffect. Ну и, конечно, всё своё влияние) И вот что получилось: 1. Приложение теперь redux-first. То есть сначала инициализируется redux, и потом уже init-saga управляет сложным процессом инициализации (минус 20 useEffect) 2. Добавил управление роутером через экшоны. Благодаря этому получилось не выпрыгивать из саг для описания flow (минус сотни useEffect) 3. Внедрил react-query для запросов, и выкинул кэш сервера из redux. В редакс остались только бизнес данные. Интегрировал через redux-saga (Минус тысячи строк кода) 4. Разделил понятия команд и событий, что позволило однозначно разделить логику между редьюссерами и сагами. 5. Описал всё это в целостной архитектуре, с чёткими ролями и обязанностями И в результате получилось охеренно. Не представляю на каком инструменте можно было бы сделать такие сложные вещи понятными и предсказуемыми. Но точно не на useEffect 🤮

Для чего я делаю свой контент и курсы Последнее время много думаю над этим вопросом. Ведь я хочу давать экспертизу, углублять ваши знания, рассказывать о сложных и глубоких вещах. Но для чего вам эта экспертиза? 🙅‍♂️ Не деньги. Сейчас деньги зависят от навыка прохождения собеседований и навыка работать на двух работах по 2 часа в день. 🙅‍♂️ Не результаты. Успешность проектов в большинстве своём — результат работы команды и качества управления. Твой уровень знания React тут не сильно решает. И только сегодня я смог для себя сформулировать ответ. В тот момент, когда сидя в ресторане почувствовал, как сильно хочу понедельника. ДА, Я С НЕТЕРПЕНИЕМ ЖДУ ПОНЕДЕЛЬНИКА Я жду, когда смогу продолжить выполнять задачу, которую я оставил в пятницу. Но при чём тут экспертиза? При том, что моя экспертиза и дарит мне это удовольствие от работы. ✔️ Она позволяет заслуживать уважение ✔️ Она позволяет влиять на архитектуру ✔️ Она позволяет брать интересные задачи ✔️ Она позволяет учить других, и получать благодарность ✔️ Она позволяет делать задачи быстро и с лёгкостью ✔️ Она позволяет не проделывать дедлайны ✔️ Она позволяет получать благодарности и результат Когда я пришёл на этот проект, мне было грустно... Разрабы не учавствуют в планировании. Технические решения принимаются не осознанно. Технологии используются не к месту. Много мешающих и бесящих меня практик в разработке и в коде. И я начал влиять, благодаря экспертизе и знаниям. Начал развивать инфраструктуру большого и сложного продукта, будучи рядовым сениором. Начал затаскивать эффективные (любимые) инструменты. Доказал ненужность бесячих практик. Предложил изменения в архитектуре и улучшения в технических метриках продукта. Это было не просто. Было сопротивление. Мне понадобилось много часов синков и много ситуаций, где я доказывал свою компетенцию. В результате я кайфую. Я изменил среду, имея силу. Очень мощную компетенцию и знания. И теперь я жду понедельника, чтобы продолжить делать любимое дело. Так, как я это люблю делать – эффективно, с отдачей и радостью. Своими курсами и контентом хочу поделиться этой силой. Дать возможность кайфовать от занятия, которым вы занимаетесть большую часть своего дня 🙂

Выпустил пятое видео про создание платформы ⬇️ https://micro-courses.ru/learn/course/micro-courses-dev/lesson/5-inversify Вообще, с переходом к более узкому формату, серия видео пошла в очень интересную сторону. Я расслабился по поводу сложности происходящего, и начали происходить даже для меня очень интересные вещи. С самого начала разработки у меня прям руки чесались затащить какой-нибудь di. Всё же привычка работы c Nest и любовь к инверсии зависимостей дают о себе знать Изначально я пошёл в сторону серверных экшонов, а там не оказалось единой точки входа. То есть непонятно, где инициализировать этот самый контейнер Но потом я решил переехать на trpc, и всё встало на свои места. Теперь точка входа в сервер – это trpc, и туда можно вынести инициализацию сервисов. Взял inversify, как самое распостранённое решение. И вот я дома) Как-то вообще без инструмента инверсии зависимостей грустно. (В React всегда это был контекст) И теперь хорошо стало. Так что, кому любопытно посмотреть, как можно подружить Next.js Inversify trpc – залетайте на видос. Он получился самодостаточным, можно смотреть в отрыве от всего курса.

Выпустил четвёртое видео из серии "Стартап с нуля до первых денег" Но не в обычном формате, а в виде бесплатного курса на платформе https://micro-courses.ru/course/micro-courses-dev Почему я так сделал? Главная причина — объём. Я планировал сделать MVP платформы примерно за 5 видео по 5 часов. Но в MVP я засунул столько механик, что делать это на видео мне придётся сильно дольше запланированного. И ладно, сделал бы. Но, к сожалению, качество при таких объёмах начинает сильно страдать. И эти видео знатно мне подпортили бы статистику на youtube. Я придумал решение, которое позволит и мне расслабиться, и вам пройти этот путь со мной до заявленного конца – подключения оплат и релиза платформы. Планирую выпускать видео по воскресеньям раз в неделю. Видео будут не очень большие, зато у меня останется время ещё на что-то в этой жизни 🥲 Кстати, эти 2 недели я страдал, пытаясь сделать то же самое, только в смотрибельном для широких масс формате. Не получилось(

Спасибо огромное за ваши комментарии под вчерашним постом! За это я и люблю то, чем занимаюсь. За возможность излить вам душу, и получить столько слов поддержки и принятия в ответ. Люблю вас ❤️

Я чувствую вину перед вами Вчера ходил к психологу. У меня в терапии огромный запрос на постоянство и ответственность. Вся моя жизнь наполнена бесконечным циклом: 1. Я встречаю новых людей 2. Почти всегда им нравлюсь своим умом, компетентностью, может личными качествами 3. Со временем я начинаю разочаровывать людей невыполнением своих обязательств Я страдаю от этой проблемы с самого раннего возраста. Ещё в школе, когда я пришёл в новый класс, всех покорил. Но уже через год потерял уважение из-за "забытых учебников, домашек, портфелей" и всякой прочей бытовухи И с вами точно такая же ситуация. Я чувствую, как я быстро теряю уважение из-за моих проектов - "вспышек", которые я не заканчиваю. У многих людей складывается ощущение, что мне пофиг. Ну забыл и забыл. На самом деле, это страдания всей моей жизни. Вся моя сущность пропитана чувством вины перед множеством людей. Перед женой, дочкой, родителями, коллегами, вами... Пока пишу об этом, перед моими глазами болью проносятся сотни ситуаций, где я опять продолбался, забыл, не смог и так далее Зачем я это пишу? Хочу принять это чувство. Всю жизнь я его блокировал. Загребал под ковёр. И становился чёрствым. Живя внутри меня, оно забирало энергию, силы, и делало меня несчастным Как говорят психологи, называя и наблюдая чувство — мы его проживаем. Только так эмоция не оставляет шрамы на душе, а уходит с миром. И этот пост, по сути, продолжение моей вчерашней терапии. Тут даже не так важна причина ситуаций, которые эту вину порождают. Это моя молодость, самоуверенность, бесстрашие. Есть объективные причины, почему я разочаровываю людей вокруг меня. Но я не должен страдать от этого. Это я. Такой, какой есть. Это можно улучшить. Но винить себя из-за этого... Я, наверное, больше не хочу 😄 P.S. новости о серии видео по платформе расскажу завтра

Мы вообще не знаем инструменты, которыми пользуемся Показательный пример с zod. Чаще всего, его как используют: как typescript, только в рантайме. Но дьявол кроется в деталях, как всегда. Они упускают множество мощных возможностей 👇🏼 ✔️ В Zod можно определять глобальные сообщения об ошибках, и не писать одно и то же по 100 раз ✔️ Можно сделать трансформации после парсинга и декларативно превращать всякие ISO строки в Date, парсить в Bitint и так далее ✔️ В Zod есть оператор pipe, который позволяет произвести повторную валидацию поля после трансформации. И, оказывается, что zod оочень классно работает с вложенными JSON строками и подобными вложенными сериализаторами ✔️ В Zod есть discriminated union, благодаря которым ошибки в схемах становятся мега информативными. Ещё и работает это быстрее ✔️ Функцию в refine можно сделать тайп гвардом и уточнить типы в процессе валидации ✔️ И много-много всего ещё И вот, кажется, простой инструмент. А на самом деле имеет мощное такое второе дно. Которое если открыть, можно стать более продуктивным. И код сделать более чистым и декларативным. Это только один zod. А теперь посмотрите на ваш список зависимостей И да, сейчас я сосредоточился на знании инструментов, чтобы вы обратили на мой курс по zod на платформе. Но есть же ещё: - Концепции, которые реализуют инструменты - Алгоритмы и структуры данных - Принципы программирования - Архитектура - Абстрактное мышление И много-много тем, которые супер важны, но игнорируются стандартной системой образования. В общем, за вот этой странной картой скрывается очень глубокая и далеко идущая идея. Если получится, будет охуенно. Если нет – как всегда повеселюсь на славу)