👨🏻 IT-блог Давида Шекунца 👴🏿
164 subscribers
1 photo
74 links
#fullstack #аналитика #data #продуктоводство #product #менеджмент #проектирование #architect etc.

А еще у меня есть хардкорный IT-проект t.me/it_kachalka

По любым вопросам, без стеснения: @davidshekunts 💋

davidshekunts.ru
Download Telegram
to view and join the conversation
Не пытайтесь сделать успешно с первого раза

Все равно не получится

Первая работа, первый коммерческий проект, первый бизнес, первое партнерство, те же первые отношения, практически никогда не заканчиваются успешно. В лучшем случае “не так плохо, как у кого-то”

Подумайте о том, что вы планируете реализовать и скажите себе: “Это просто попытка, я ничего от нее не жду, надо просто попробовать” - вас сразу же отпустит

Свобода совершить ошибку и провалиться дадут силы начать задуманное

#thoughts
(статья) Хорошо жить запретишь или Немного поддержки маленьким студиям

Расскажу пару принципов, которые когда-то помогли нам в Three Zeta Studio и нашим коллегам продвинуться на рынке.

Если вкратце:
1. Вас вытянет первый большой клиент (точнее, его топ-менеджмент)
2. Проект, который принесет опыт в сфере, на базе которого вы сможете собрать собственный продукт

Чтобы дожить до одного из этих событий вам понадобится упорство, чтобы оставаться достаточно долго на плаву, голос, чтобы громко и ясно заявлять о себе и честь, чтобы обязательно доводить заказы до конца, даже если это выйдет вам в минус.

Удачи

https://davidshekunts.ru/2020/01/20/horosho-zhit-zapretish-ili-nemnogo-podderzhki-malenkim-studiyam/

#it #business
(отчет) Встреча с Федором Борщевым (15.01) и "Проектная пятница" (24.01)

Отчитаюсь сразу за 2 мероприятия:

(1) Встреча с Федором Борщевым (блог) прошла просто прекрасно!

Эту встречу замечательно описал Федор Ирхин:
"Зацепило общее дружелюбие, расслабленность и большое количество необычных людей. Были и начинающий кодер, и фронтендер-тимлид, и создатель веб-студии, и даже основатель крупного российского сервиса.

Сперва отвечал только Фёдор, но потом участники тоже расслабились и включились в беседу. Вопросы были как чисто техническими так и философскими.

Под конец встречи тебе спокойно, потому что понимаешь: не знать и искать ответы - это нормально."

Мы делились советами, рассказывали интересные истории и смеялись в приятной атмосфере с кофейком.

Всем очень советую следить за мероприятиями Коворкафе. Они проходят каждую среду и там часто встречается "годнота". Например, следующая встреча с Федором пройдет 19-го февраля.

(2) "Проектная пятница" (сайт)

Очень драйвовое мероприятие, где встречаются за бокальчиком вина куча топ-менеджеров от частных предприятий до самых крупных представителей индустрии.

В процессе проводятся "горячие столы" на разные тематики и игра "Проектное мышление", в которой я принял участие.

Игра "Проектное мышление" похожа на "Монополию", во время которой вы сидите с томом правил и пытаетесь реализовать проект, когда все катиться под откос. Очень свежо и драйвово. Одна партия длится 2-3 часа, но все настолько динамично, что ты даже близко не замечаешь, насколько быстро пролетает время. Схоже ли это с реальным ведением проектов и можно ли что-то перенять для своей работы? Поразительно, но да.

В остальном, мы выпивали, кушали вкусняшки, обсуждали самые горячие новости и сетовали на сложности в своих проектах :) Вы руководитель проекта? Отдых и моральная поддержка на этом мероприятии будет вам обеспечена!

Проводится это мероприятие раз в месяц, следите за новостями на сайте + я буду публиковать анонсы на своем канале.

#events
____
(статья) Немного о том, как создавать уникальные IT-проекты без кода

"No code" площадки – сервисы, позволяющие создавать уникальные проекты и автоматизации без использования кода, то есть, через визуальные редакторы.

Мы уже давно работаем с подобными сервисами (Tilda, WordPress, IFTTT, etc.), но рынок растет и появляются новые решения, решил поделиться парочкой, которые меня очень заинтересовали:

Makerpad – это площадка обучения тому, как эффективно использовать решения рынка "no-code". Здесь вы найдете большой список "no-code" сервисов, видео-курсы и сможете заказать помощь специалистов.

Проекты Adalo и Glideapps позволяют создавать мобильные приложения без кодинга, с динамическими данными на Google Sheets.

Sheet2Site – создание сайтов без кодинга, используя Google Sheets, как Базу Данных.

Airtable предлагает потрясающее и очень известное за рубежом решение по организации данных. Очень напоминает Notion на стероидах.

Actiondesk.io помогает интегририровать множество разных источников данных (БД, CRM, ERP, etc.) в одну таблицу. Это вам и Аналитика и BI, и CRM, и собирательная БД в одном инструменте.

Memberstack.io позволяет скрыть контент на сайте, сделав его доступным только для конкретных "участников" проекта. Шикарное решения для создания "контента на подписке".

https://davidshekunts.ru/2020/02/07/nashe-budushhee-sozdanie-it-proektov-bez-koda-statya-s-primerami/

#top #it #nocode #tech

___
(статья) Главное качество специалиста или "Правило бинарного мудака"

Если вы боитесь, что вас кто-то обманет и пытаетесь это предотвратить, то сначала спросите себя: "может, он – мудак?" - если ответ "да", тогда что бы вы не сделали, он вас обманет. А если ответ "нет", то об обмане и думать не придется.

Важнее всего задать этот вопрос и найти на него ответ на этапе приема человека в команду.

Как понять мудак ли я как руководитель? Если вы "требуете", значит вы – мудак, если вы "помогаете" и "поддерживаете", значит вы – немудак. Читать Servant leadership

Как понять мудак ли я как исполнитель? Если вы готовы намеренно обмануть коллег, не готовы брать ответственность и помогать в тяжёлых ситуациях проекта, требуете, но не готовы работать ни секунды дольше положенного, поздравляю, вы – почетный мудак.

Как понять передо мной мудак или нет? Доверьтесь интуиции. Спросите у его бывших / нынешних коллег и руководства (минимум у нескольких человек)

Почему бинарный? Здесь не бывает полумер, если специалист "полумудак" округляйте до "мудака".

Что делать с мудаками? Ничего, ничего с ними не делайте. Покиньте это место.

А если там всего один мудак? Если это не руководитель, то пообщайтесь со своим руководителем, он подскажет.

А с какими мудаками встречались вы и что делали? Пишите в комментариях, интересно узнать ваши истории

Чуть больше в статье: https://davidshekunts.ru/2020/02/07/glavnoe-kachestvo-speczialista-ili-metod-binarnogo-mudaka/

#it #stories #rulethemall

__
(сервисы) Boom от VK — "очень плохая музыка"

Одним из главных сценариев стриминговых сервисов наших дней является "умный" подбор музыки, когда достаточно нажать «Play» и всегда будет играть музыка, которую вы хотите здесь и сейчас.

Для того, чтобы этого добиться, стриминговым сервисам нужны данные о пользователе, и чем больше, тем лучше можно спрогнозировать его желания.

Я пользовался Deezer (фаворит), Spotify и BOOM. Все они имеют достойный интерфейс, функционал и "умный" плейлист, но есть один очень паршивый момент у Boom...

Еще с бессознательных времен я использую VK. Наверное, 20% всего времени, проведенного в интернете я провожу в VK: списываюсь, читаю посты, ищу видео и слушаю музыку.

Причем, я слушаю очень много неизвестных локальных групп со всего мира, которых не найти на других ресурсах. В основном это трип хоп, дарк джаз, нью метал, мат-рок, транс стонеры и подобное. И этих треков у меня добавлено тысячи.

Эти данные бесценны, о них мечтает любой стриминговый сервис. На базе данных предпочтений и истории поиска, музыка ВК могла бы подбирать мне треки бесконечной чередой утопических симфоний.

Но эта сука в «Рекомендациях» предлагает мне Элджея и какого-то блять «lil chill»… И это уже на протяжении года... Я думал, что пользуясь сервисом он под меня адаптируется, но нет!

Почему так? Сервис то хороший, но иметь такую силу и не пользоваться ей – грех…

Честно, я не знаю как повлиять на эту ситуацию, поэтому пишу сюда, но как только у меня будет возможность, я обязательно схвачу кого-нибудь из VK и спрошу за это. Если у вас есть контакты кого-то из команды, развивающей BOOM, буду рад с ними пообщаться.

P.S. Кстати, мне подписка на BOOM досталась бесплатно вместе с кучей ништяков из https://combo.mail.ru/

P.P.S. Еще крутую продуктовую историю о стриминговых сервисах советую послушать в видеоподкасте Ивана Замесина с руководителем Яндекс.Музыки Андреем Геваком https://zamesin.me/podcast-andrey-gevak-full/

__
(отчёт) Стратпица IT-agency "Про менторов и эдвайзеров" (13.02.20)

Это было прекрасное мероприятие, больше похожее на групповую беседу, во время которой десяток СТО, СЕО и несколько команд поделились своим опытом работы с менторами, эдвайзерами и консультантами

Из крутых мыслей выделю:

1. Брать платные сессии советов у конкурентов.

Каким бы вы не были профессионалом, чужая позиция может дать новый подход к осознанию вашего опыта. Эта позиция ни лучше, ни хуже вашей, ценность в том, что она другая.

2. Делать консультации и презентации успешных практик для своих конкурентов.

Этот кейс рассказал один из участников: он намерено шел в фирмы конкурентов и выступал у них с презентациями успешного опыта. Во-первых, он мог получить разные позиции и мнения насчёт этих практик, во-вторых, если конкурент также успешно мог ей воспользоваться, ее можно было систематизировать.

3. В одной из фирм было правило повышения грейда: общаться минимум с 10-ю профессионалами не ниже своего уровня на постоянной основе.

То есть, вас не поднимут по карьерной лестнице, если вы не предоставить доказательства, что общаетесь вне рабочего времени с другими профи из вашей сферы (Вау)

4. Одна из главных мотиваций ментора — возможность быть полезным, и это часто ценнее денег.

И я полностью с этим соглашусь, потому что сам неоднократно давал скидки или не брал денег вообще, когда понимал, что реально помог людям, чувствовал что они благодарны. Этот даёт настоящую ценность моей деятельности.

5. Чтобы грамотно делегировать какую-то обязанность, надо сделать "слепок" знания о ней.

Одним из самых крутых скиллов руководителя является возможность быстро узнать достаточное количество информации о компетенции, которую он хочет делегировать. Это позволяет понятно выставить задачу и качественно оценить результат. Иначе остаётся только сжать кулачки (и пукан) в надежде на удачу, а не это лучшая тактика в управлении.

Для этого было предложение: пообщаться со знающими людьми (1-3 человека), посмотреть видео, почитать статьи и в конце, если нужно, прочитать пару глав из книг по теме. Причем именно в такой последовательности, поскольку разговор с человеком будет с конкретикой под вашу ситуацию, а книги могут потребовать дни и недели на осознание и подгонку под вашу ситуацию.

Если обобщить все что было сказано: (1) платите за знания людей, у которых они уже есть, это окупиться в разы, (2) работайте над расширением своего круга общения, это вопрос не только профессионального, но и духовного развития.

Спасибо ребятам за эту встречу!

Здесь вы сможете посмотреть анонсы их будущих мероприятий https://www.it-agency.ru/events

#event #it
Методика "Ты сделаешь это за час или я отрежу тебе палец!?"

Пару мыслей про оценку времени задач.

"Кто ответственный за срок?"

Не решайте сколько времени займет задача исполнителя. Всегда спрашивайте время на решение задачи у того, кто будет ей заниматься.

Если вы хотите, чтобы между вами сложились доверительные отношения (а без них успеха не видать), вам придётся начать доверять первым и дать возможность исполнителю самому оценивать задачи.

Когда это заработает, вы перестанете терять кучу времени и сил на контроль людей и они будут вам благодарны за доверие, а благодарность повышает продуктивность.

Еще один аргумент в пользу доверия – правило «бинарного мудака»: если человек мудак, как бы вы не хотели контролировать его время, он вас все равно обманет. А немудаку надо просто помочь сделать правильную оценку.

"Как тогда контролировать срок выполнения?"

Оценке задач по времени — это НЕ метод контроля («опоздаешь, накажем!»), это метод прогноза.

Если вы не укладываетесь в срок, значит нужно не давить на исполнителей («ты сделаешь это за час или я отрежу тебе палец!?»), а начать разговор про оптимизацию или приоритезацию задач.

Исполнитель, если и снизит время проекта, то должен сделать это сам, без прессинга, иначе из страха он может сказать срок гораздо меньше реального, и в итоге будет просрочка. Ругаться и сетовать что вас «обманули» будет бессмысленно, потому что сделали это из-за страха, который Вы же и культивировали.

Именно в такую ловушку фирмы часто себя загоняют: дедлайны прогорают потому что под прессингом команда обещает то, чего выполнить не сможет.

А у вас в команде, случайно, нет такой проблемы? Пообщайтесь с коллегами нет ли у них дискомфорта называть вам срок решения задачи. Спросите как они себя почувствуют, если им надо попросить еще больше времени на решение задачи.

Если человек не испытывает дискомфорта, значит вы – хороший руководитель и перед вами зрелый сотрудник, если дискомфорт связан с личными проблемами, попробуйте помочь человеку стать увереннее этом месте, если есть дискомфорт по отношению к вам или другому руководителю постарайтесь поработать над своей политикой выставления задач.

Для простоты проведения этого опроса, сделайте его анонимным, в виде опроса в Google Forms / TypeForm. Это снизит напряжение. Но я всегда ЗА именно живое общение один на один, после анонимных опросов.

"Как назначать задачи?"

О хорошем способом передачи задач рассказывает Федор Борщев – техника «пуш» и «пулл» (читать обязательно)

«Пуш» – это когда вы впихиваете задачи в исполнителей, даже если не впихуется.

«Пулл» – это когда вы показываете задачи спринта и исполнители сами выбирают какие будут делать.

В технике «пулл» меньше прессинга, и вы научитесь лучше приоритизировать задачи, поскольку уже не сможете их просто впихнуть людям.

"Что если он джун не может сказать время?"

Чтобы научиться говорить время на решение какой-либо задачи, нужно начать говорить время на решение задачи. Ошибаться и корректировать себя по итогам. Поэтому попросите его предположить, а по итогу сверьте ожидание и реальность. Да, будут ошибки, но вы чего хотели? Это джун.

Лайфхак. Для простоты советую указывать время на задачу в степени двойки (1, 2, 4, 8, 16), но не более 16 часов на задачу. Если задача требует более 16-ти часов, значит ее надо декомпозировать.

Вместо итога

Старайтесь меньше впихивать задач и больше передавать ответственности своим людям. Ответственность в правильных руках хорошо мотивирует.

#it #rulethemall

___
(q&a) Метод «выйдем поговорим», как способ улучшения атмосферы в команде

«У нас стартап (до 10 разработчиков), что можно сделать, чтобы лучше понимать настроение людей?»

Так называемый «one-o-one» или проще разговор один на один – это лучший способ понимать как дела у членов команды. И я сейчас говорю не о случайных пересечениях на кухне или по скайпу, а о заранее назначенных еженедельном часе общения один на один. Еще раз: нужно заранее договорится о (полу)часе каждую неделю / две на обычный совместный разговор с каждым членом команды.

Если в команде становится слишком много человек, то придется начать это делегировать на кого-то другого, но: (1) время от времени разговаривать самому (хотя бы раз в месяц), (2) тот, кому вы делегируете должен быть доверенным и близким команде лицом (не HR, который просто «послушает и запишет»)

Как начать? Прям завтра определите свои свободные часы и скажите своей команде, чтобы каждый взял по часу разговора на следующей неделе.

Что это даст? Все любят внимание, особенно когда оно уделено полностью. Это момент исповеди, время за которое вы сможете узнать что мешает человеку получать удовольствие и приносить пользу.

Просто попробуйте сами или предложите начальству.
(q&a) Как приучить себя прогонять тесты без CI/CD

«У нас нет автоматической запуска тестов, настраивать CI/CD сейчас точно не получится, но хочется помочь разработчикам не забывать их прогонять перед пушем в репозиторий?»

Вижу два варианта: (1) ставить автоматизацию прогона тестов перед git push или (2) скриншоты рабочих тестов в PR

Первый вариант, мне лично, не очень нравится, потому что: (1) его нужно настраивать у каждого разработчика на компьютере, (2) у вас нет доказательств, что человек просто их не выключил, (3) они не всегда правильно работают.

А вот скриншоты тестов решают эти проблемы:

Во-первых, в регламенте появляется обязательный пункт наличия скриншотов тестов в PR, значит их нельзя забыть сделать.

Во-вторых, это гарантия для других, что они были сделаны.

Да, это не решает проблемы, что человек может закоментить куски проблемного кода, прогнать тесты, сделать скрины, выложить их и раскомментировать неработающий код, но это значит, что у вас проблема с наймом.

P.S.
Нужно понимать, что это решение – костыль. Реальным решением являются: рефакторинг кода так, чтобы тесты могли работать «в вакууме» и подключение хоть какой-нибудь системы автоматической прогонки тестов (Travis, Gitlab CI/CD, CircleCI и т.п.).
(статья) Как я выбирал редактора

Давненько я ничего не писал. Почему? А потому что все это время выбирал редактора, который будет помогать мне.

И вот, прособеседовав около 40-ка человек, я выбрал того самого. И теперь, чтобы закрыть гештальт, хочу поделиться с вами результатами моего отбора и полученным опытом.

Внимание! Статья в основном для редакторов, но подойдет и для других специалистов, которые продают свои услуги частникам

Статья: https://docs.google.com/document/d/13s3yxJ8Puh_3ObB0AZQtMMA7d-beuNwyvcIh1G-sO40/edit?usp=drivesdk
(q&a) “А как ты видишь ‘качественный backend’?”

Почти все подрядчики задают этот вопрос и, чтобы не повторяться, укажу пару основных пунктов:

1. Посмотрите вот это видео: https://www.youtube.com/watch?v=ANrmiJrnkew – элегантно, лаконично и прямо в точку. Это относится к любому backend (с или без framework) на любом языке

2. Код, должен быть покрыт тестами. Особенно MVP. Об этом будет следующий мой пост, упомяну лишь, что фраза: “без тестов будет в 2-3 раза быстрее!” – сразу отказ от работы

3. Говнокод – это нормально. Важно, чтобы разработчики (1) понимали почему его пришлось здесь использовать, (2) знает как и нужно ли вообще улучшать его, (3) покрыли тестами

4. Знание что такое “Entity”, “Aggregate”, “UseCase”, “Repository”, слои из DDD, Clean Architecture, CQRS, DI, IoC. Этого не нужно придеживаться на 100% (иначе можно сделать enterpise даже из ToDo list), но важно понимаение этих концепций, их преимуществ и недостатков. Материалы для изучения приложу к следующим статьям.

5. Понимать какие есть варианты реализации API кроме CRUD

Это далеко не все, я бы сказал, это минимум, но его достаточно, чтобы быть спокойным, что мы сможем напилить качественный код
(статья) Пара интересных наблюдений про циклы разработки

Скрумы, Агили или еще что у вас, это неважно, если вы работаете циклами / итерациями / спринтами, то вам может быть полезно:

1. Как и зачем привлекать заказчика на каждом цикле
2. Типизация тасков, которая показывает “здоровье” спринта
3. Алгоритм формирования задач и вероятности проеба дедлайна

Эта статья особенно актуальна тем, с кем я планирую работать, поэтому если у вас есть мысли / дополнения / возражения, всем велком в ЛС, с удовольствием обсужу

Статья: https://davidshekunts.ru/2020/04/04/cziklotimiya-razrabotki/
(tech) Что передавать по WebSockets? JSON-RPC

Мы все знаем, что есть такое понятие, как JSON REST API – по определенным урлам, которые означают ресурсы, вы передаете JSON объекты, в Headers устанавливаете дополнительные данные (например, Authorization token) и в сессии запроса “синхронно” получаете ответ в виде JSON с нужными данными. Тут все просто.

Но как быть с WebSockets (WS)? Да и вообще с асинхронными протоколами? Что и куда передавать (body, headers) и как понимать, что ответ пришел на конкретный запрос?

Тут все тоже просто: протокол RPC. А в данном случае JSON-RPC. И я говорю о “протоколе”, как о правилах описания объекта запросов и объекта ответов.

Этот протокол просто описать самому на любом языке программирования и для работы с любым асинхронным обменом данных (WS, MQTT, для MQ и так далее) и для любого вида взаимодействия (межсервисное, сервер-клиент, клиент-клиент).

Наверное, самое понятное объяснение реализации и примеры библиотек можно найти здесь https://ru.wikipedia.org/wiki/JSON-RPC

Если найдете объяснение лучше, то напишите мне
(tech) Vertical Slice Architecture

Крутая и простая архитектура, для построения backend на любом языке и framework. Всем backend-разработчикам к просмотру обязательно.

Эта архитектура является некоторым развитием мысли DDD, CQRS и Clean Architecture, но знать их наперед необязательно, чтобы попробовать Vertical Slice Architecture.

Кстати, здешние декораторы очень напомнили устройство authorization, validation, logging и подобное в framework, но тут все эти вещи вынесены с уровня контроллеров на уровень сервисов, что позволяет потрясающе абстрагивароться от конкретной реализации API и переиспользовать бизнес-логику.

Разжеванный пример Vertical Slice Architecture буду давать в моем грядущем курсе вебинаров про “DDD для MVP”

1. https://www.youtube.com/watch?v=SUiWfhAhgQw (eng)
2. https://www.youtube.com/watch?v=qJPwSvDLmQE (rus)
3. Статья по 2-му видео: https://habr.com/ru/company/jugru/blog/447308/
(tech) Полезные ссылки по DDD, CA, CQRS, Repository, Node.js и так далее

Собираю небольшое вики с ссылками на крутые статьи, видео и примеры кода. Буду постоянно его пополнять, так что сохраняйте в закладочки.

Например, там есть ссылка на парня, который в самых дотоншых деталях рассказывает как сделать чистый DDD на Node.js + TS и дает несколько репозиториев с примерами проектов. Просто бомба. Писать так в проектах не стоит (слишком дорого и сложно), НО знать эти концепции и взять самое вкусное, обязательно нужно. Даже если вы пишите на другом языке и framework, можно своровать у него множеством концепций.

https://davidshekunts.ru/2020/04/18/ddd-light-dlya-mvp-poleznye-ssylki/
(tech) Хотите, чтобы в вашем коде были тесты и комментарии? TDD + CDD

Ни один программист в здравом уме не горит желанием покрывать что-либо тестами или комментариями уже после того, как он это написал.

Если вы хотите, чтобы ваш код был покрыт тестами и комментариями, то надо начинать писать код именно с них.

С тестами все понятно, для этого существует методология Test Driven Development (TDD), которая рассказывает нам про красный -> зеленый -> синий циклы: сначала пишем тесты (красный), потом пишем код, который пройдет все тесты (зеленый), а потом рефакторим его (синий).

А угадайте как называется подход с комментариями? Правильно – Comment Driven Development (CDD). Здесь у нас серый и цветной циклы: сначала пишем что должно произойти комментариями (серый), потом уже пишем код (цветной).

Примеры кода в статье по ссылке

! Тизер !
Совсем скоро, я начну выпускать цикл статей по современному подходу к быстрой разработке крупных, тестируемых и надежных backend приложений.

Там встретятся такие понятия как: DDD, CQRS, Clean Architecture, Repository, AOP, ROP и многое другое.

Для примера я буду использовать NodeJS + TypeScript, но эти принципы распространяются на любые языки и framework.

Интересно? Тогда ставьте лайк под этим постом и я ускорю работу над контентом.

——
(tech) Энциклопедия “Domain Driven Design Light”

Здесь вы найдете приемы, которые помогают писать и масштабировать самый кровавый enterprise: от техник изучения бизнес-аспектов проекта и построения документации, до подробного объяснения (с примерами) основ DDD, CQRS, CA, ROP, AOP, IoC, TDD / BDD, EDA, SOA, Error Handling, Validation, Constraints, Modularity, Vertical Slices, BFF, RDM, ADM.

+ Вышел обновленный список полезных материалов, в который я добавил: (1) пять repository с проектами, использующими вышеописанные концепции и (2) прекрасный видос с презентацией про валидацию данных и как написать свой фреймворк валидации. Весь новый контент идет с префиксом “(NEW)”.

!Дэйнджер! Данные контенты достаточно сложные для восприятия. Чтобы въехать во все более плавно, ожидайте скорого выхода курса, в котором я буду с нежностью матери разжевывать каждую концепцию и интегрировать в учеников.

Вводная глава Экнциклопедии: https://davidshekunts.ru/2020/05/14/ddd-light-chto-eto-i-zachem-eto/
Глава “Полезные ссылки”: https://davidshekunts.ru/2020/04/18/ddd-light-dlya-mvp-poleznye-ssylki

Всем чмок 💋

Курс Аху🔥нное приложение на Node.js & TypeScript & DDD Light

На этом курсе мы научимся разрабатывать крупные Node.js TypeScript приложения.

Вы – middle Backend-ер, Team lead или Project manager с командой, которая пишет современные Node.js приложения и хотите, чтобы вся команда умела:

⚡️ Быстро добавлять новые фичи
🤸🏽‍♂️ Писать гибкий к изменениям код
🩹 Быстро обнаруживать и «безвозвратно» чинить баги
☺️ Получать удовольствие от кодинга

Тогда этот курс для вас.

Вы получите:

📖 Конкретный набор правил (регламентов)
⚙️ Примеры кода
Ссылки на кучу полезных материалов по теме
📼 Видео, в которых я рассказываю и показываю примеры реализаций
🕸 А также пример Open source проекта

Интересно? Хотите получить этот курс 🔥бесплатно🔥?

Нужно просто подписаться на мой телеграм-канал (@davidshekunts_blog) и приглашайте товарищей.

Ссылка на первую статью курса: https://davidshekunts.ru/2020/05/23/kurs-prilozhenie-na-node-js-typescript-ddd-light-nachalo/

По всем вопросам в ЛС (@davidshekunts) 💋

-