Вы правы, для чувствительных данных, таких как логин, пароль от базы данных, нужно использовать как минимум env переменные. Не добавили этого в статью, чтобы не усложнять пример. Чтобы попробовать фичи - достаточно скопировать и вставить, без создания переменных, откуда будут браться логины и пароли. Что насчет портов: мы указали порт для базы данных, чтобы иметь возможность подключиться к ней из API, запущенного в IDE. Спасибо за совет, посмотрим в сторону бинда на локальный хост :)
Да, отличная идея добавить healthcheck. Мы используем эту фичу в наших других проектах, но для простоты примера не добавили её в статье, чтобы сфокусироваться на представленных выше фичах. Спасибо за совет!
Да, вы правы, можно использовать внешнюю переменную окружения. Но мы выбрали этот кейс как простой пример использования шаблонов сервисов. Нам, например, может понадобиться изменить скрипт в одном из копий сервиса, и для того, чтобы не копировать весь сервис, используем шаблон Спасибо за совет о docker compose, учтем!
Можно поставить любые расширения в связке ide+docker-compose, но тогда их либо придется ставить внутрь контейнера + vs code туда же, либо, если использовать docker-compose чисто для сборки и билда, расширения придется ставить локально. Dev контейнеры же легко позволяют устанавливать расширения именно в контейнер.
Зависит от того, что вам нужно. Мы, например, используем расширения VS Code для поддержки синтаксиса языка, для удобного взаимодействия с Cmake, для написания документации и поддержки Mermaid и многие другие. Удобно, когда нужное расширение одним кликом можно добавить в контейнер.
Конечно, можно. Но зачем, если в dev контейнерах это уже автоматизировано? Что нужно делать с docker-compose: прокидывать volume с хоста, устанавливать расширения, настраивать IDE в контейнере. Что нужно сделать с dev контейнером: кликнуть на кнопку.
Это немного разные технологии с разным фокусом: docker compose – средство для запуска и управления контейнерами, dev containers – средство для контейнерной разработки. Да, можно настроить контейнер через docker compose и использовать его для контейнерной разработки, но это будет сложнее. Dev контейнеры уже интегрированы в среду разработки, их использовать проще.
Очень справедливое замечание про шаблоны. Мы используем шаблон компании, однако даже тут порой возникают сложности, если информация на слайде не подходит под шаблон. Примеры из статьи не претендуют на окончательный вариант дизайна презентации, а больше иллюстрируют содержание статьи. Наши рекомендации помогают нам на крупных российских конференциях. Надеемся, кому-то они тоже смогут помочь.
Приветствуем, Юпитер. Вы правы, существует еще множество полезных советов по подготовке хорошей презентации, в том числе не связанных с ее оформлением. Может быть, мы расскажем о них в следующей статье;)
Как раз хороший пример консистентности. У примера с черепахоенотами уникальная и более подходящая для этого конкретного случая композиция, в то же время он не выбивается из общего стиля и согласован с другими примерами.
У нас стенд стоит в офисе, и в нем нет никаких кулеров, на процессоре, например, просто стоит большой радиатор. Так сервер не издает никакого шума и не мешает тем, кто находится с ним рядом. Когда выбирали видеокарту, опирались на кол-во видеопамяти, а также на то, насколько она шумная, вот почему выбор пал на теслу. Но как оказалось просто радиатора недостаточно для охлаждения видеокарты.
Спасибо вам за интересное мнение! Хотелось бы немного порассуждать на эту тему.
Прежде всего, я считаю, что отсутствие сроков может негативно сказаться на проекте, приводя к постоянным доработкам, желанию добавить новый функционал или дополировать уже готовый и, в результате, к бесконечному растягиванию времени выполнения проекта. Как мне кажется, сроки устанавливают определенные рамки, в которые необходимо вписываться, и помогают избежать бесконечных доработок.
Из этого вытекает следующий важный момент. Чем дольше проект находится в работе, тем выше вероятность, что он утратит свою актуальность, станет ненужным и не будет соответствовать быстро развивающимся технологиям.
Также мне кажется, что отсутствие предварительных сроков сильно ограничивает возможность планирования. Как для заказчика, который хочет знать, когда получит готовый продукт, и спланировать дальнейшие действия. Так и для исполнителя, который может работать над несколькими проектами, каждый из которых требует грамотного планирования и внимания. Еще оценка помогает определить приблизительные затраты на проект (если это не фикс прайс, конечно). На мой взгляд, для заказчика важно иметь представление о приблизительной стоимости проекта. Без возможности спланировать сразу и время, и приблизительный бюджет проекта заказчику будет трудновато.
Как вы верно отметили, у некоторых клиентов могут быть слишком оптимистичные и завышенные ожидания, поскольку они не всегда осознают объем работы. По моему мнению, если мы не будем занижать эти ожидания в процессе обсуждения проекта, существует бóльшая вероятность столкнуться с тем, что заказчика не устроит скорость работы. В таком случае, часть работы будет проделана, а оставшаяся часть будет доделываться с большим напряжением из-за обманутых ожиданий. Объясняя оценку и занижая ожидания, мы заранее готовим заказчика к реальному времени выполнения проекта, он ментально настраивается на это и это помогает избежать неправильных представлений о сроках и разочарований.
Ну и наконец, как мне кажется, важно помнить, что это заказчик обращается за услугой, а не наоборот. Если бы я, как клиент, обратилась за услугой в другой сфере и по срокам мне бы ответили: "Будет готово, когда мы закончим", я вряд ли бы стала обращаться снова к этому исполнителю. Всё-таки в наших интересах установить хорошие отношения с клиентом, оправдать его ожидания и принести пользу.
“Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов”. На мой взгляд, горе руководители всегда найдут, над чем охать и ахать. Опять же это ответственность исполнителя установить контакт с клиентом, создать комфортный процесс работы и сделать все возможное, чтобы не допустить для себя “ненормальных дедлайнов” и жуткого стресса. В конце концов, если уже на первоначальном этапе не удается установить нормальный диалог с клиентом, можно отказаться от совместной работы.
Было бы крайне интересно узнать ваше мнение относительно этих рассуждений:)
TS не защитит вас в рантайме. Если придет что-то другое, то вы это TS не излечите и он вам об этом ничего не скажет.
Интеграционные тесты API должны гарантировать, что эта штука все ещё работает. Тесты API на контракт тоже должны быть здесь. e2e тесты клиента должны проверять полную интеграцию для минимального user happy path.
Недавно мы начали разрабатывать проукты через TDD, в довольно строгом смысле. Это требует наличия инфраструктуры, которая поддержвает все уровни тестов, включая линтинг от TS.
Как мы решаем тот случай, о котором вы говорите:
API предоставляет контракт в виде npm пакета с автосгенерированным TS кодом (в нашем случае поверх gRPC и protobuff). Следуем SemVer: патч, фича или мажорный апдейт контракта сервиса.
BFF на NestJS использует пакет с типами от API везде в коде. Не создаем дополнительные слои DTO.
В контроллерах в обязательном порядке маппим данные перед отправкой на клиент, чтобы в рантайме не ушло больше чем мы хотим.
Если меняется, используемый API, то обновляем его npm-пакет и смотрим отвалилось ли что по TS линтингу и тестам всех остальных уровней: юнит тесты BFF, интеграционные тесты BFF, e2e тесты клиента.
При этом во фронте у нас проект без TS.
В целом мне в BFF очень нравится такой флоу работы. В фронтенде при работе со своим BFF мы стараемся идти в сторону только обратно совместимых изменений API, чтобы не афектить старый UI и новый UI. И только после того, как старого не остается ни у кого, тогда клинапим BFF обратнонесовместимым обновлением. Следуем подходу двухфазного деплоя.
Не соглашусь с вами. Не буду размышлять на тему что такое react way и есть ли он вообще. Или на тему того, что хуки это может быть очень спорное решение и некоторые простые вещи приходится писать через одно место.
Нельзя ориентироваться на useState и считать это истинным react way. Это просто одна из многих функций и вот она так реализована и это имеет смысл. Это не значит, что все надо делать так на автомате.
А вот у нас коллегам было не так очевидно, что объект лучше, чем массив. Было мнение что массив, как у useState, это react way.
Мы долго обсуждали оставить ли исключение для случая с 1 параметром, особенно, если это какая-то id. Также и про 2 параметра. Сошлись на том, что всем проще всегда оборачивать в объект, чем принимать такие решения. С ростом числа аргументов вовремя решаться на рефакторинг не всегда удается даже опытным разрабочикам. А ещё не ясно как проводить ревью.
Работаем с зарубежными «большими пацанами». 3 года назад TS был в опале, сейчас ситуация поменялась, он используется по умолчанию. Есть большая проблема того, что те, кто не писал бекенд и начал сразу с фронтенда и работает давненько просто используют TS ужасно и становится хуже чем без него. Хотя опять же это скорее не проблема TS как такового, а проблема Engineering Excellence для этой конкретной команды.
Мы бы сказали, что если команда не может выстроить нормальную архитектуру решения без TS, то с ним станет все только хуже. Такая же история с применением DDD, когда в команде и без него никто не может сделать простое понятное решение.
Штука с generics в том, что они абсолютная пушка, например, в C#. Но в JS они были всегда, вся эта утиная типизация, все итак уже generic. Это одна из самых сложных тем, которой надо учить коллег фронтендеров, знакомящихся с TS. Дается тяжело, хотя они всегда так и работали, просто не явно и это им ничего не стоило.
Презентовали эту идею опытным иностранным коллегам, все задумались, было очень интересно это отметить. Всем показалось, что есть смысл, но ведь так никто не делает. Ещё было интересное опасение, что при таком подходе, когда очень просто расширять код без изменения клиентов, куда проще писать говнокод.
Мы решили делать так для начала только в своей команде. У нас там нет TS, поэтому выглядит очень изящно и джунам проще сориентироваться, пока книга «Чистый код» ещё не осилена. Пробуем в другом проекте, где есть TS, выглядит куда более громоздко.
Вы правы, для чувствительных данных, таких как логин, пароль от базы данных, нужно использовать как минимум env переменные. Не добавили этого в статью, чтобы не усложнять пример. Чтобы попробовать фичи - достаточно скопировать и вставить, без создания переменных, откуда будут браться логины и пароли.
Что насчет портов: мы указали порт для базы данных, чтобы иметь возможность подключиться к ней из API, запущенного в IDE. Спасибо за совет, посмотрим в сторону бинда на локальный хост :)
Да, отличная идея добавить healthcheck. Мы используем эту фичу в наших других проектах, но для простоты примера не добавили её в статье, чтобы сфокусироваться на представленных выше фичах. Спасибо за совет!
Спасибо, узнали что-то новое, исправим!
Да, вы правы, можно использовать внешнюю переменную окружения. Но мы выбрали этот кейс как простой пример использования шаблонов сервисов. Нам, например, может понадобиться изменить скрипт в одном из копий сервиса, и для того, чтобы не копировать весь сервис, используем шаблон
Спасибо за совет о docker compose, учтем!
Да, действительно используем docker desktop. Посмотрим в сторону rancher desktop, спасибо :)
Можно поставить любые расширения в связке ide+docker-compose, но тогда их либо придется ставить внутрь контейнера + vs code туда же, либо, если использовать docker-compose чисто для сборки и билда, расширения придется ставить локально. Dev контейнеры же легко позволяют устанавливать расширения именно в контейнер.
Зависит от того, что вам нужно. Мы, например, используем расширения VS Code для поддержки синтаксиса языка, для удобного взаимодействия с Cmake, для написания документации и поддержки Mermaid и многие другие. Удобно, когда нужное расширение одним кликом можно добавить в контейнер.
Конечно, можно. Но зачем, если в dev контейнерах это уже автоматизировано?
Что нужно делать с docker-compose: прокидывать volume с хоста, устанавливать расширения, настраивать IDE в контейнере.
Что нужно сделать с dev контейнером: кликнуть на кнопку.
Это немного разные технологии с разным фокусом: docker compose – средство для запуска и управления контейнерами, dev containers – средство для контейнерной разработки. Да, можно настроить контейнер через docker compose и использовать его для контейнерной разработки, но это будет сложнее. Dev контейнеры уже интегрированы в среду разработки, их использовать проще.
Очень справедливое замечание про шаблоны. Мы используем шаблон компании, однако даже тут порой возникают сложности, если информация на слайде не подходит под шаблон. Примеры из статьи не претендуют на окончательный вариант дизайна презентации, а больше иллюстрируют содержание статьи. Наши рекомендации помогают нам на крупных российских конференциях. Надеемся, кому-то они тоже смогут помочь.
Приветствуем, Юпитер. Вы правы, существует еще множество полезных советов по подготовке хорошей презентации, в том числе не связанных с ее оформлением. Может быть, мы расскажем о них в следующей статье;)
Как раз хороший пример консистентности. У примера с черепахоенотами уникальная и более подходящая для этого конкретного случая композиция, в то же время он не выбивается из общего стиля и согласован с другими примерами.
У нас стенд стоит в офисе, и в нем нет никаких кулеров, на процессоре, например, просто стоит большой радиатор. Так сервер не издает никакого шума и не мешает тем, кто находится с ним рядом. Когда выбирали видеокарту, опирались на кол-во видеопамяти, а также на то, насколько она шумная, вот почему выбор пал на теслу. Но как оказалось просто радиатора недостаточно для охлаждения видеокарты.
Спасибо вам за интересное мнение! Хотелось бы немного порассуждать на эту тему.
Прежде всего, я считаю, что отсутствие сроков может негативно сказаться на проекте, приводя к постоянным доработкам, желанию добавить новый функционал или дополировать уже готовый и, в результате, к бесконечному растягиванию времени выполнения проекта. Как мне кажется, сроки устанавливают определенные рамки, в которые необходимо вписываться, и помогают избежать бесконечных доработок.
Из этого вытекает следующий важный момент. Чем дольше проект находится в работе, тем выше вероятность, что он утратит свою актуальность, станет ненужным и не будет соответствовать быстро развивающимся технологиям.
Также мне кажется, что отсутствие предварительных сроков сильно ограничивает возможность планирования. Как для заказчика, который хочет знать, когда получит готовый продукт, и спланировать дальнейшие действия. Так и для исполнителя, который может работать над несколькими проектами, каждый из которых требует грамотного планирования и внимания. Еще оценка помогает определить приблизительные затраты на проект (если это не фикс прайс, конечно). На мой взгляд, для заказчика важно иметь представление о приблизительной стоимости проекта. Без возможности спланировать сразу и время, и приблизительный бюджет проекта заказчику будет трудновато.
Как вы верно отметили, у некоторых клиентов могут быть слишком оптимистичные и завышенные ожидания, поскольку они не всегда осознают объем работы. По моему мнению, если мы не будем занижать эти ожидания в процессе обсуждения проекта, существует бóльшая вероятность столкнуться с тем, что заказчика не устроит скорость работы. В таком случае, часть работы будет проделана, а оставшаяся часть будет доделываться с большим напряжением из-за обманутых ожиданий. Объясняя оценку и занижая ожидания, мы заранее готовим заказчика к реальному времени выполнения проекта, он ментально настраивается на это и это помогает избежать неправильных представлений о сроках и разочарований.
Ну и наконец, как мне кажется, важно помнить, что это заказчик обращается за услугой, а не наоборот. Если бы я, как клиент, обратилась за услугой в другой сфере и по срокам мне бы ответили: "Будет готово, когда мы закончим", я вряд ли бы стала обращаться снова к этому исполнителю. Всё-таки в наших интересах установить хорошие отношения с клиентом, оправдать его ожидания и принести пользу.
“Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов”. На мой взгляд, горе руководители всегда найдут, над чем охать и ахать. Опять же это ответственность исполнителя установить контакт с клиентом, создать комфортный процесс работы и сделать все возможное, чтобы не допустить для себя “ненормальных дедлайнов” и жуткого стресса. В конце концов, если уже на первоначальном этапе не удается установить нормальный диалог с клиентом, можно отказаться от совместной работы.
Было бы крайне интересно узнать ваше мнение относительно этих рассуждений:)
Спасибо за совет! Возьмем на заметку этот метод.
Да, так и есть :) Иногда не создаем типы, чтобы использовать их 1 раз. Хотелось честно показать, как не очень это может выглядеть вместе с TS.
TS не защитит вас в рантайме. Если придет что-то другое, то вы это TS не излечите и он вам об этом ничего не скажет.
Интеграционные тесты API должны гарантировать, что эта штука все ещё работает. Тесты API на контракт тоже должны быть здесь. e2e тесты клиента должны проверять полную интеграцию для минимального user happy path.
Недавно мы начали разрабатывать проукты через TDD, в довольно строгом смысле. Это требует наличия инфраструктуры, которая поддержвает все уровни тестов, включая линтинг от TS.
Как мы решаем тот случай, о котором вы говорите:
API предоставляет контракт в виде npm пакета с автосгенерированным TS кодом (в нашем случае поверх gRPC и protobuff). Следуем SemVer: патч, фича или мажорный апдейт контракта сервиса.
BFF на NestJS использует пакет с типами от API везде в коде. Не создаем дополнительные слои DTO.
В контроллерах в обязательном порядке маппим данные перед отправкой на клиент, чтобы в рантайме не ушло больше чем мы хотим.
Если меняется, используемый API, то обновляем его npm-пакет и смотрим отвалилось ли что по TS линтингу и тестам всех остальных уровней: юнит тесты BFF, интеграционные тесты BFF, e2e тесты клиента.
При этом во фронте у нас проект без TS.
В целом мне в BFF очень нравится такой флоу работы. В фронтенде при работе со своим BFF мы стараемся идти в сторону только обратно совместимых изменений API, чтобы не афектить старый UI и новый UI. И только после того, как старого не остается ни у кого, тогда клинапим BFF обратнонесовместимым обновлением. Следуем подходу двухфазного деплоя.
Не соглашусь с вами. Не буду размышлять на тему что такое react way и есть ли он вообще. Или на тему того, что хуки это может быть очень спорное решение и некоторые простые вещи приходится писать через одно место.
Нельзя ориентироваться на useState и считать это истинным react way. Это просто одна из многих функций и вот она так реализована и это имеет смысл. Это не значит, что все надо делать так на автомате.
А вот у нас коллегам было не так очевидно, что объект лучше, чем массив. Было мнение что массив, как у useState, это react way.
Мы долго обсуждали оставить ли исключение для случая с 1 параметром, особенно, если это какая-то id. Также и про 2 параметра. Сошлись на том, что всем проще всегда оборачивать в объект, чем принимать такие решения. С ростом числа аргументов вовремя решаться на рефакторинг не всегда удается даже опытным разрабочикам. А ещё не ясно как проводить ревью.
Решили проблему не решать :)
Работаем с зарубежными «большими пацанами». 3 года назад TS был в опале, сейчас ситуация поменялась, он используется по умолчанию. Есть большая проблема того, что те, кто не писал бекенд и начал сразу с фронтенда и работает давненько просто используют TS ужасно и становится хуже чем без него. Хотя опять же это скорее не проблема TS как такового, а проблема Engineering Excellence для этой конкретной команды.
Мы бы сказали, что если команда не может выстроить нормальную архитектуру решения без TS, то с ним станет все только хуже. Такая же история с применением DDD, когда в команде и без него никто не может сделать простое понятное решение.
Штука с generics в том, что они абсолютная пушка, например, в C#. Но в JS они были всегда, вся эта утиная типизация, все итак уже generic. Это одна из самых сложных тем, которой надо учить коллег фронтендеров, знакомящихся с TS. Дается тяжело, хотя они всегда так и работали, просто не явно и это им ничего не стоило.
Презентовали эту идею опытным иностранным коллегам, все задумались, было очень интересно это отметить. Всем показалось, что есть смысл, но ведь так никто не делает. Ещё было интересное опасение, что при таком подходе, когда очень просто расширять код без изменения клиентов, куда проще писать говнокод.
Мы решили делать так для начала только в своей команде. У нас там нет TS, поэтому выглядит очень изящно и джунам проще сориентироваться, пока книга «Чистый код» ещё не осилена. Пробуем в другом проекте, где есть TS, выглядит куда более громоздко.
Посмотрим labeled tuples, спасибо :)