Наконец добрался до списка инструментов из TechnologyRadar. Выделил для себя следующее:
Devbox🤔
Инструмент который позволяет вам легко создавать изолированные оболочки для разработки. Можно сохранить всё в конфиг json и положить в гит. Нужно пробовать. Если реализовано нормально, то точно стоит затащить в рабочие проекты.
Как проверю в бою, поделюсь опытом :)
Ссылка: https://www.jetify.com/docs/devbox/
Difftastic😐
Подсветка изменений в коде на основе синтаксиса, а не тупо “текста”. Выглядит интересно, но судя по всему затащить в GitLab не получится, так что для большинства задач неприменим.
Visual regression testing tools🚬
Кое-что из мира тестирования. В эту категорию попадают BackstopJS, Applitools и Percy. Такие инструменты позволяют отслеживать визуальные изменения. Под капотом оно просто сравнивает всё с эталонным интерфейсом с помощью скриншотов и предупреждает, если что то разъехалось. За последние пару лет очень хорошо выросла точность, поэтому верю, что этим начнут пользоваться более массово.
ClickHouse😐
Старичок ClickHouse, придуманный Яндексом в далеком 2009 году.
Можно сказать уже классика. Знать про этот инструмент необходимо каждому, очень уж он распространён. На одном ХХ сейчас 1100 вакансий с упоминанием ClickHouse 😊
Unleash😋
Удобный инструмент для работы с фича флагами. Избавляет от необходимости лишний раз изобретать велосипед
Ссылка: https://www.getunleash.io/
Mockoon😘
Просто комбайн для создания моков API под любые задачи. Рекомендую и для бэков и для фронтов.
Ссылка: https://mockoon.com/
ReadySet⌨️
Прослойка для кэширования запросов для MySQL и Postgresql. Располагается между БД и приложением. А еще умеет автоматически обновлять кэшированные запросы при изменении данных. Звучит очень вкусно, есть ли подвох?)
uv🔫
Убийца pip и virtualenv в одном флаконе, написанный на Rust от разработчиков линтера ruff. Попробовать точно стоит. Первый релиз был в начале 2024 года, а теперь у проекта уже 35 тысяч звёзд.
Ну и куда же без AI:
ColPali - лучший инструмент для извлечения информации из PDF. Еще и самый быстрый.
Cursor - целая IDE заточенная на разработку с помощью AI.
Semantic Router - удобный и быстрый инструмент для понимания намерений пользователя. из текста.
Devbox
Инструмент который позволяет вам легко создавать изолированные оболочки для разработки. Можно сохранить всё в конфиг json и положить в гит. Нужно пробовать. Если реализовано нормально, то точно стоит затащить в рабочие проекты.
Как проверю в бою, поделюсь опытом :)
Ссылка: https://www.jetify.com/docs/devbox/
Difftastic
Подсветка изменений в коде на основе синтаксиса, а не тупо “текста”. Выглядит интересно, но судя по всему затащить в GitLab не получится, так что для большинства задач неприменим.
Visual regression testing tools
Кое-что из мира тестирования. В эту категорию попадают BackstopJS, Applitools и Percy. Такие инструменты позволяют отслеживать визуальные изменения. Под капотом оно просто сравнивает всё с эталонным интерфейсом с помощью скриншотов и предупреждает, если что то разъехалось. За последние пару лет очень хорошо выросла точность, поэтому верю, что этим начнут пользоваться более массово.
ClickHouse
Старичок ClickHouse, придуманный Яндексом в далеком 2009 году.
Можно сказать уже классика. Знать про этот инструмент необходимо каждому, очень уж он распространён. На одном ХХ сейчас 1100 вакансий с упоминанием ClickHouse 😊
Unleash
Удобный инструмент для работы с фича флагами. Избавляет от необходимости лишний раз изобретать велосипед
Ссылка: https://www.getunleash.io/
Mockoon
Просто комбайн для создания моков API под любые задачи. Рекомендую и для бэков и для фронтов.
Ссылка: https://mockoon.com/
ReadySet
Прослойка для кэширования запросов для MySQL и Postgresql. Располагается между БД и приложением. А еще умеет автоматически обновлять кэшированные запросы при изменении данных. Звучит очень вкусно, есть ли подвох?)
uv
Убийца pip и virtualenv в одном флаконе, написанный на Rust от разработчиков линтера ruff. Попробовать точно стоит. Первый релиз был в начале 2024 года, а теперь у проекта уже 35 тысяч звёзд.
Ну и куда же без AI:
ColPali - лучший инструмент для извлечения информации из PDF. Еще и самый быстрый.
Cursor - целая IDE заточенная на разработку с помощью AI.
Semantic Router - удобный и быстрый инструмент для понимания намерений пользователя. из текста.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥12👍2
В последнее время всё чаще говорят про инструменты для Python, написанные на Rust. Видимо на фоне успехов Astral с ruff и uv лёд тронулся. На это накладывается кратно возросшая популярность Rust, который за 4 года уверенно поднялся с 35 места до 20 места по популярности (смотреть тут). А там совсем рядом Swift и Go, про которые точно все слышали.
Пока общий процент пакетов на Rust от общего всё еще небольшой. Это ruff, uv, polars, ripgrep и плюсом инструменты для интеграции PyO3 и maturin. Сама интеграция выглядит и правда максимально просто. Один из самых простых примеров с хабра тут.
Хочется верить, что Rust еще посоревнуется с C/C++, на котором еще с древности пишут все оптимизации/инструменты, которые должны работать быстро. Из причин вижу несколько:
- современный язык
- высокая производительность
- не течёт память, меньше вероятность ошибки
- меньше уязвимостей в коде
Посмотрим, что будет дальше.
Пока общий процент пакетов на Rust от общего всё еще небольшой. Это ruff, uv, polars, ripgrep и плюсом инструменты для интеграции PyO3 и maturin. Сама интеграция выглядит и правда максимально просто. Один из самых простых примеров с хабра тут.
Хочется верить, что Rust еще посоревнуется с C/C++, на котором еще с древности пишут все оптимизации/инструменты, которые должны работать быстро. Из причин вижу несколько:
- современный язык
- высокая производительность
- не течёт память, меньше вероятность ошибки
- меньше уязвимостей в коде
Посмотрим, что будет дальше.
1👍4🔥4🤔2
Ура, друзья. Вот и долгожданный юбилей, нас ровно 200 😋
Please open Telegram to view this post
VIEW IN TELEGRAM
1🎉19👍2🔥2❤1
Пусть Python и считается самым простым языком для изучения, это не отменяет существования сотен тонкостей и подводных камней.
Так уж у нас прижилось, что
Так же на эту тему есть пара интересных примеров сукрал одолжил с StackOverflow)
Пример №1
Случай редкий, да и визуально может показаться, что всё нормально. Просто вспомним, что такие операторы нельзя использовать с функциями, а так же с объектами, которые не реализуют iadd и add.
Пример №2
А всё почему? А потому, что`.extend()`
#python #разработка
Так уж у нас прижилось, что
.extend() и обычное присваивание некоторые разработчики считают равноценными. Но это ошибка, так как .extend() изменяет существующий список, а сложение создает новый список из двух переданных.Так же на эту тему есть пара интересных примеров с
.extend() и оператором += (Пример №1
list1 = [5, 6]
list2 = [7, 8]
def get_list():
return list1
get_list().extend(list2) # ✅ Работает
get_list() += list2 # ❌ SyntaxError
Случай редкий, да и визуально может показаться, что всё нормально. Просто вспомним, что такие операторы нельзя использовать с функциями, а так же с объектами, которые не реализуют iadd и add.
Пример №2
my_tuple = ([1, 2], [3, 4], [5, 6])
my_tuple[0].extend([10, 11]) # works
my_tuple[0] += [10, 11] # TypeError
А всё почему? А потому, что`.extend()`
изменяет список на месте, а += пытается создать новый список и присвоить его элементу кортежа, что невозможно, так как кортеж — неизменяемый.#python #разработка
1👍10
Кажется январь - официально месяц утечек данных.
Тут собрал вам ссылочек, кому интересно:
Утечка Otelier https://www.bleepingcomputer.com/news/security/otelier-data-breach-exposes-info-hotel-reservations-of-millions
Утечка у Альфа-групп https://www.securitylab.ru/news/545057.php?muid=d26eadd9-8aea-48c2-9ec4-52542c2ea51d
Утечка у Ростелекома https://habr.com/ru/news/875312/
Утечка из китайских сервисов https://cybernews.com/security/chinese-data-leak-expose-didi-weibo-kfc-communist-party/
Утечка Hewlett Packard Enterprise https://habr.com/ru/news/875230/
Подробности как обычно не раскроют, но всё равно показательно - проблемы с безопасностью есть даже у крупных компаний с деньгами. Страшно представить, как с этим обстоят дела у компаний поменьше. Уверен, что там и про пентест врятли кто-то слышал.
Тут собрал вам ссылочек, кому интересно:
Утечка Otelier https://www.bleepingcomputer.com/news/security/otelier-data-breach-exposes-info-hotel-reservations-of-millions
Утечка у Альфа-групп https://www.securitylab.ru/news/545057.php?muid=d26eadd9-8aea-48c2-9ec4-52542c2ea51d
Утечка у Ростелекома https://habr.com/ru/news/875312/
Утечка из китайских сервисов https://cybernews.com/security/chinese-data-leak-expose-didi-weibo-kfc-communist-party/
Утечка Hewlett Packard Enterprise https://habr.com/ru/news/875230/
Подробности как обычно не раскроют, но всё равно показательно - проблемы с безопасностью есть даже у крупных компаний с деньгами. Страшно представить, как с этим обстоят дела у компаний поменьше. Уверен, что там и про пентест врятли кто-то слышал.
1🆒2🔥1😱1
На всех рабочих проектах достаточно старые версии docker и docker-compose. И вот я сам не заметил, как проспал важное изменение: version в docker-compose файлах теперь можно не указывать 😎
Даже warning добавили:
#docker
Даже warning добавили:
the attribute 'version' is obsolete, it will be ignored, please remove it to avoid potential confusion#docker
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5👀3
В этой статье расскажу о своём опыте работы в VR-шлеме, какие инструменты использую, и поделюсь советами по настройке. Возможно, это побудит вас попробовать такой формат работы и создать своё идеальное виртуальное рабочее пространство.
https://habr.com/ru/articles/876720/
На фото мой Quest 3. Кажется ему скоро будет год😎 Всё еще радует)
https://habr.com/ru/articles/876720/
На фото мой Quest 3. Кажется ему скоро будет год
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍5❤2
Еще раз убедился, что нужно фиксировать ВСЕ зависимости. Всегда.
Жили-были два пакета: jsonschema и typing_extensions. Были строго зафиксированы их версии. Всё работало 3 с лишним месяца, но сегодня при обновлении одного из стендов мы узнали, что эти два пакета несовместимы и проект больше не стартует.
jsonschema начал валится в ошибку:
Помогло изменение версии jsonschema вниз, либо поднятие typing_extensions вверх. Но ведь раньше они работали вместе, так что продолжили поиски.
В итоге всё таки нашли виновника - в requirements не было пакета referencing. Он начал подтягиваться с версией 0.36.0, вместо предыдущей 0.35.1 и всё сломал.
Лучше один раз зафиксировать всё, чем потом несколько часов разбираться.
Жили-были два пакета: jsonschema и typing_extensions. Были строго зафиксированы их версии. Всё работало 3 с лишним месяца, но сегодня при обновлении одного из стендов мы узнали, что эти два пакета несовместимы и проект больше не стартует.
jsonschema начал валится в ошибку:
TypeError: TypeVar.__init__() got an unexpected keyword argument 'default'
Помогло изменение версии jsonschema вниз, либо поднятие typing_extensions вверх. Но ведь раньше они работали вместе, так что продолжили поиски.
В итоге всё таки нашли виновника - в requirements не было пакета referencing. Он начал подтягиваться с версией 0.36.0, вместо предыдущей 0.35.1 и всё сломал.
Лучше один раз зафиксировать всё, чем потом несколько часов разбираться.
1❤5🤔4🌚2💯2
Сегодня попробовал в деле Goose. Это свежий ai-агент, который буквально вчера официально релизнулся. Сильно впечатлен.
Смысл в этом простой - цепляем его к любой LLM через API-key. Ставим задачу. Он её выполняет с помощью своих "расширений". Умеет взаимодействовать с браузером и с компьютером. Заявлена интеграция и с JetBrains, но пока не понял, в какой момент он к ним обращается.
Отправил его писать тесты на один из пет-проектов, сказал ему где искать окружение. Подсказал, что заодно будет хорошо дополнить requirements. Ну а дальше он в своем внутреннем цикле выполняет задачу.
К примеру вот так он доводит до ума неработающие тесты:
В конце он просто сдался. После 3-4х часов отладки хочется сделать так же...
Подробнее можно почитать в статье на Хабре:
https://habr.com/ru/articles/877522/
Смысл в этом простой - цепляем его к любой LLM через API-key. Ставим задачу. Он её выполняет с помощью своих "расширений". Умеет взаимодействовать с браузером и с компьютером. Заявлена интеграция и с JetBrains, но пока не понял, в какой момент он к ним обращается.
Отправил его писать тесты на один из пет-проектов, сказал ему где искать окружение. Подсказал, что заодно будет хорошо дополнить requirements. Ну а дальше он в своем внутреннем цикле выполняет задачу.
К примеру вот так он доводит до ума неработающие тесты:
─── shell | developer ──────────────────────────
command: cd /home/kisel/PycharmProjects/crew_ai && source .venv/bin/activate && PYTHONPATH=$PYTHONPATH:$PWD/proj/src pytest proj/src/bot/test_handlers.py
Я понял свою ошибку. Я использовал `side_effect` неправильно. `side_effect` нужен, когда нужно выполнить код, вместо того чтобы просто подменить функцию. В мое
м случае мне нужно подменить декоратор на функцию, которая ничего не делает.
Я уберу `side_effect` и буду использовать `return_value=mock_only_authorized`
В конце он просто сдался. После 3-4х часов отладки хочется сделать так же...
Подробнее можно почитать в статье на Хабре:
https://habr.com/ru/articles/877522/
1🔥4❤1
В PyCharm 2024.3.2 появилась поддержка uv для управления окружениями. Теперь можно создавать новые виртуальные среды с его помощью или применять uv к уже существующим. Особенно удобно это при импорте проектов из VCS — PyCharm сам предложит использовать uv.
Еще кое-что интересное — flame graph в профилировщике (доступен в Professional-версии). Он позволяет наглядно увидеть, какие части кода занимают больше всего времени при выполнении. Теперь проще находить узкие места в производительности, устанавливать пороги, искать нужные методы и детально изучать дерево вызовов.
Еще кое-что интересное — flame graph в профилировщике (доступен в Professional-версии). Он позволяет наглядно увидеть, какие части кода занимают больше всего времени при выполнении. Теперь проще находить узкие места в производительности, устанавливать пороги, искать нужные методы и детально изучать дерево вызовов.
👍4👀2
Посетил тут Moscow Python №98. В этот раз он проходил в том же здании, где находится штаб-квартира МТС-Банка. Жалко, что не было экскурсии в сам офис — всех сразу посадили в зал для конференций.
В программе три очень разные темы. Это всегда большой плюс и к кругозору, и к интересу. 🙂 Рассказывали про нейросети в защите данных, про применение SAGA-паттерна и про RPA (Robotic Process Automation) систему на Питоне.
Для себя понял, что:
- Нейросети могут быть очень быстрыми даже на обычном железе. Обрабатывать миллион файлов в корпоративной сети — реальная задача, уже можно не бояться.
- Пора бы уже подтянуть паттерны для микросервисной архитектуры. Про SAGA я даже не слышал до этого момента. Видимо, мне просто везло, и всегда хватало знать самые распространённые.
- Никогда не пойду разрабатывать RPA, ни за какие деньги. Селекторы для HTML, картинки-шаблоны для поиска кнопочек, сложности тестирования и куча других проблем... Вот когда туда заедут AI-агенты — можно будет подумать. 😄 А пока всё вручную…
С этого митапа мне запомнился один персонаж. Вы же знаете, что на митапах принято рассказывать про свои ошибки и делиться их решениями? Думаю, да. А один мужик в зале, видимо, об этом не слышал. В конце рассказа про внедрение SAGA последовал вопрос: «Ну, у вас, я так понимаю, пет-проект. А вы не пробовали нанять архитектора?» 😎
Видимо, это был автор или главный последователь фразы «Чтобы не было ошибок в коде — пишите код без ошибок». И самое страшное — он, скорее всего, кем-то руководит…
В программе три очень разные темы. Это всегда большой плюс и к кругозору, и к интересу. 🙂 Рассказывали про нейросети в защите данных, про применение SAGA-паттерна и про RPA (Robotic Process Automation) систему на Питоне.
Для себя понял, что:
- Нейросети могут быть очень быстрыми даже на обычном железе. Обрабатывать миллион файлов в корпоративной сети — реальная задача, уже можно не бояться.
- Пора бы уже подтянуть паттерны для микросервисной архитектуры. Про SAGA я даже не слышал до этого момента. Видимо, мне просто везло, и всегда хватало знать самые распространённые.
- Никогда не пойду разрабатывать RPA, ни за какие деньги. Селекторы для HTML, картинки-шаблоны для поиска кнопочек, сложности тестирования и куча других проблем... Вот когда туда заедут AI-агенты — можно будет подумать. 😄 А пока всё вручную…
С этого митапа мне запомнился один персонаж. Вы же знаете, что на митапах принято рассказывать про свои ошибки и делиться их решениями? Думаю, да. А один мужик в зале, видимо, об этом не слышал. В конце рассказа про внедрение SAGA последовал вопрос: «Ну, у вас, я так понимаю, пет-проект. А вы не пробовали нанять архитектора?» 😎
Видимо, это был автор или главный последователь фразы «Чтобы не было ошибок в коде — пишите код без ошибок». И самое страшное — он, скорее всего, кем-то руководит…
4🔥5👍2🤔2
Интересная статистика на HH есть, оказывается. Графики говорят сами за себя - конкуренция увеличилась (с 6.1 до 8.5), а количество вакансий просело в лучшем случае на 20%. Сложно сказать за бэкенд, но довольствуемся "Информационными технологиями" :)
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
🤯3👍2
Fullstack-разработчик - худший выбор, который можно сделать для своей карьеры в IT. Плюсов у этого решения нет, зато минусов - целый вагон.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?ХАХА, НЕТ .
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
1💯7🔥5😁2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2🤔1
Вы знали, что существует флоу, в котором просто нет тестировщиков? Совсем. Меня такой подход сильно удивил. И речь именно о крупных проектах, которые не жмутся за каждого человека в штате.
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?💻
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👀4🤔3👍2