Задать вопрос
  • Индексация идёт уже 2 недели, в чем у меня ошибка?

    @rPman
    значит узкое место почти наверняка диск.

    Пальцем в небо, файловая система на которой таблеспейсы лежат какая? случайно не cow (btrfs/zfs/xfs)? с ними отвратительно работают базы данных, так как частые записи в файл генерируют сильную фрагментацию. В этом случае перед тяжелой обработкой хотя бы дефрагментируй файлы базы и отключи cow фичу на таблеспейсах

    неплохим тюнингом может оказаться (на выбор):
    * разместить базу в ram диске (буквально, залить на сервер в облаке, обработать данные, залить назад, работая напрямую с таблеспейсами, но версия софта должна совпадать до последней цифры)
    * разместить базу целиком на ssd (даже если это будет потребительский и дешевый)
    * добавить в систему ssd кеш для hdd с помощью например bcache (включенный на запись), правда для линейной обработки базы это может дать мало пользы, но вообще это неплохой способ на порядок поднять производительность за дешево (в одном месте я использовал фичу virtualbox со снапшотами в файл, есть и у kvm, когда последующие записи шли не на исходный образ а на другой диск, и он ssd)
    * разместить таблеспейс для индексов (а может и каждую таблицу отдельно) на другом физическом устройстве (hdd, ssd или даже в ram), требования к размеру тут обычно низкие, ключевое слово - исключить последовательные чтения/записи на одно устройство.
    * разместить журнал (например ext4) на ssd диск (хватит пары гигабайт) или по хардкору даже отключить его (очень опасно, можно получить кашу из данных при сбое питания, но как временное решение пока идет долгая операция, при наличии всех бакапов, оправдано) - наименьшая оптимизация, но при частых мелких записях это заметно
    Ответ написан
  • Присутствуют ли в TypeScript ООП-штуки, из тех что описываются в книжках по паттернам проектирования?

    bingo347
    @bingo347 Куратор тега TypeScript
    Crazy on performance...
    Дизайн паттерны абстрагированы от языка и работают практически везде одинаково. Некоторый отпечаток может наложить на них динамическая типизация, как в JS, но даже тут сильно ничего не поменяется.
    Кроме того, в корне не верно приписывать паттерны к ООП. Они абсолютно одинаково работают во всех парадигмах, за некоторыми небольшими исключениями.
    Ну и наконец, ООП часть в TS прямо слизана с Java, так что многие примеры будут даже выглядеть похоже.
    Ответ написан
    3 комментария
  • Проблема в "нерандомности" рандома или ошибка в реализации?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    В C#, при создании объекта Random без параметра, он инициализируется системным временем, которое имеет конечное разрешение. Если два объекта созданы с одним значением инициализатора, то они будут выдавать одинаковую последовательность.
    В вашем случае надо один раз до цикла создавать объект Random, а в цикле только вызывать его метод Next.
    Ответ написан
    3 комментария
  • Что принципиально отличает Symfony 5 от Laravel 8?

    myks92
    @myks92
    Нашёл решение — пометь вопрос ответом!
    1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
    2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
    3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
    4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
      Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.

    Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

    Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.
    Ответ написан
  • Количество фреймворков для фронта и бэка?

    Devilz_1
    @Devilz_1
    Frontend-Developer
    Пару строк занудства, если позволите:
    Друзья программисты мне говорят не соваться во фронт, так как там постоянно выходят новые фреймворки

    :-D
    React Vue или Angular

    Ну и в скором времени к ним может присоединиться Svelte

    Теперь непосредственно к вопросу. И мой имхо ответ: нигде.

    А вообще совет откровенно говоря странный и попахивает предвзятостью))

    Моё мнение - если ты только встаёшь на стезю IT специалиста
    spoiler
    тыщу раз подумай надо ли тебе это
    нужно отталкиваться не от того, что много или мало либ и фреймворков выходят на какой-либо технологии, а от того, что нравится, от того, от чего горят глаза и потеют ладошки (и нет, это не то о чём кто-то мог подумать :-D ). Пусть у этой технологии хоть каждые полгода выходят либы. Неважно. Будь то web, mobile или desktop разработка.

    Банально. Согласен, но так и есть.
    Ответ написан
    Комментировать
  • Что лучше выучить, Java или C#?

    azerphoenix
    @azerphoenix Куратор тега Java
    Java Software Engineer
    Язык является инструментом. Важны ваши навыки, как разработчика (алгоритмы, структуры данных, понимание tcp/ip и т.д.)
    Что касается выбора языка, то ориентируйтесь на:
    - что вы собираетесь на нем делать и кем планируете работать. Если например, речь о геймдеве, то конечно же C# (Unity) или C++. И тут Java ну никак... хоть и позволяет писать игры. Если enterprise, то да, тут уже можно выбирать между Java & C#.
    - ориентируйтесь на то, где вы планируете работать. Возможно, что вы в результате вашего исследования поймете, что Java популярнее C# (или наоборот), но на деле окажется, что в вашей стране/городе она вовсе не популярна. Соответственно, посмотрите какие компании есть у вас в городе (если планируете работать офлайн) и изучите их стек.
    Ну и конечно же пробуйте. Я например, пока дошел до Java, успел попробовать PHP & JavaScript. В любом случае, когда вы станете востребованным и опытным специалистом, то уже будете владеть несоклькими языками.
    Ответ написан
    Комментировать
  • Писать типы вначале или рассчитывать на вывод типов компилятором?

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

    Если вы НЕ указываете тип, и рассчитываете на автовывод, то значит вам нужен не какой-то конкретный тип, а ТАКОЙ ЖЕ, КАК И... где-то ещё. Например, такой-же-как тип константы или такой-же-как тип возвращаемого значения функции. Иными словами, если я пишу:
    const id = findIdByName("abc");
    то мне не так важно, какой конкретно тип будет иметь id, мне важно чтобы это был тип возвращаемого значения функции "findIdByName". Для меня это приоритетно. Более того, если в какой-то момент тип возвращаемого значения у этой функции поменяется, то этот код продолжить компилироваться и, вероятно, даже РАБОТАТЬ (это зависит уже от того, что мы потом собираемся делать с id).

    Совершенно противоположная ситуация - интерфейсы. В широком смысле. Интерфейсы функций, интерфейсы классов, интерфейсы в смысле типов данных, создаваемых с помощью "interface". Особенно если эту функцию/класс/интерфейс использует много кто ещё. Тогда наоборот, вам НЕЛЬЗЯ допустить, чтобы типы параметров или тип возвращаемого значения просто так поменялись. Это вдвойне важно, если вы пишите библиотеку и речь идёт о её публичном интерфейсе - любое изменение интерфейса тогда должно подкрепляться версионированием (например, семантическим). Вы не можете просто так, тем более по недосмотру, вместо числа начать возвращать из функции строку - вы сломаете ваших клиентов, причём даже не знаете как и где.
    Ответ написан
    Комментировать
  • Писать типы вначале или рассчитывать на вывод типов компилятором?

    @antares4045
    Вопрос сугубо религиозный. Если у вас в команде нет требований к кодстайлу, то пишите так, как вам проще и не парьтесь.

    Но если включить на время зануду, то очень хочется отметить, что вы взяли тайпскрипт чтобы всеравно писать на js. Все эти истории с автоматическим выводом типов выводила людей из себя: пропустив одну букву они получали программу которая работает, но делает что-то не то. И если эта "одна буква" где-то в корнер кейсе, то ошибка может оставаться незамнченой годами. Можно покрывать весь код юнит тестами. Но это долго и бизнес (по крайней мере средний) на такие траты ни за что не пойдёт. К тому же в тестах тоже могут быть косяки... И тут люди "вспомнили" о ещё одном способе избегать такого рода ошибок: если пользователь сам распишет типы, то совсем грубые семантические ошибки компьютер отловит: тайпсерипт специально сделан, чтобы ваш код не запускался.

    Но как вы и сами отметили, проблему ошибок в коде попытплись заткнуть заставив програмиста писать больше кода в котором тоже могут быть ошибки и в результате большая часть времени уходит на "любювь с статическим анализатором". Если вы достаточно уверены в себе и в тех, кто будет поддерживать ваш код, то наверное лучше потратьте время на написание осмысленого кода а не боллерплейта, который позволят просто убедится, что вы не допустили совсем простых ошибок.
    Ответ написан
    Комментировать
  • Как начинающему фронтенд-разработчику не утонуть в океане знаний?

    DollyPapper
    @DollyPapper
    Вы понимаете, что этот вопрос это вопрос о том, что будет завтра? Никто не знает, что будет завтра. Может вы придете работать, а там не будет БЭМ, значит он вам не пригодился. Но вдруг будет? Если с основными технологиями определится легко, то есть js,css, html это однозначно нужно сейчас, нужно завтра, и послезавтра нужно. С выбором конкретной технологии тоже вроде не сложно. React? Ну учите его и ищите вакансии только по нему. А вот с методологиями и прочим делом уже сложнее. Тот же БЭМ не известно. Если взять выборку из 20 компаний, 10% из них может их не использовать, или наоборот - использовать могут 90%. Тут уже ничего сказать нельзя. Какую методологию, архитектуру, сборщик, препроцессор и прочие вещи используют в компании знают только в этой компании. По этому нужно понять принципы которые за этими вещами стоят и зачем они нужны. Мне вот например совершенно похер какой будет сборщик на проекте, я просто открою документацию и понеслась. А я даже не фронт. Просто фокус в том, что я понимаю зачем они. Что вам по сути нужно чтобы использовать любой сборщик? 1) значить зачем нужен сборщик 2) знать js. Всё! Вы знаете любой сборщик, детали самого сборщика почитаете в доках при необходимости. Выберите сейчас один и изучите его. Выберите один препроцессор, поймите его. Выберите один фреймворк, изучите его. Идите на собес. Если повезло, вы работаете, если нет изучаете то на чем завалились.
    понять для чего нужно и как это применить

    Вот в этом весь ключ
    Ответ написан
    Комментировать
  • Отделение бизнес логики от фреймворка Symfony?

    Maksclub
    @Maksclub Куратор тега PHP
    maksfedorov.ru
    Генератор — просто инструмент для помощи, по итогу сущности чисты, не считая аннотаций/атрибутов для маппинга в ORM, но это просто мета-информации и завязка не существенна (не считая маленького компромисса с ArrayCollection). То есть если вы выберите др ORM, то эти аннотации вам не помешают никак, просто лишние заюзанные классы аннотаций

    Имея сущности доктрины — у нас не связанный от фреймворка код, пишите спокойно бизнесуху, не обращая внимания на то, как оно потом маппится. То есть практически все по каннонам

    Чтобы отделить репозиторий от домена — просто в домене делайте интерфейс, а вот реализация этого репозитория будет в Infrastrucure Layer, но это избыточно... риск минимальный, если сделаете не совсем по канону, а именно риск стоит как основной аргумент такового отделения (не просто же вы словам следуете, а причину понимаете?)
    Разработка строится на компромисах, если смените доктрину на др ORM — так и так писать новые репозиторий, вероятность низкая и многие например не делают такие интерфейсы — слишком усложнит код...
    Вам надо будет просто репозиторий в маппинге ORM\Repository заменить в таком случае

    Некоторые компании пишут интерфейсы и сильно усложняют код, но тк риск минимальный изменений, то такое усложнение приводит как правило к усложнению и не более. Следуйте здравому смыслу.
    Мой довод нельзя раскручивать "ну раз минимальный, то завяжусь по полной". Все же отделение логики надо делать

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

    617588c41bdde421641847.png
    Ответ написан
    8 комментариев
  • Можно ли использовать сервисы в rich моделях?

    Maksclub
    @Maksclub Куратор тега PHP
    maksfedorov.ru
    а? Если нет и нужно все равно писать абсолютно всю логику в обьекте модели, то тогда он станет просто god обьектом на 100500 строчек

    Потому что вы все делаете наоборот!

    Пишите по бизнес-процессу ваши UseCase, это некоторый хэндлер к примеру
    Пример
    final class HandleCheckOutShoppingCart
    {
        public function __construct(Carts $carts, PaymentGateway $gateway)
        {
            $this->carts   = $carts;
            $this->gateway = $gateway;
        }
    
        public function __invoke(CheckOutShoppingCart $command) : void
        {
            $shoppingCart = $this->carts->get($command->shoppingCart());
    
            $payment = $this->gateway->captureCharge($command->charge());
    
            $shoppingCart->checkOut($payment);
        }
    }


    Потом у вас вырисовываются границы сущности, и в сущностях уже инварианты, которые контролирует эта сущность. Никаких god object
    Ответ написан
    5 комментариев
  • Микросервисная архитектура: насколько микро? и почему не возникает проблем с долгим ожиданием?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Вы задаётесь очень сложными вопросами, развёрнутый ответ на каждый из которых вряд ли влезет в лимит символов ресурса. Чтобы разобраться с первой проблемой, стоит прочитать "Предметно-ориентированное проектирование" Эванса. Грубо говоря, микросервис должен оперировать небольшим самостоятельным подмножеством данных. Для поиска ответов на вторую и третью проблему хорошим стартом может быть "Высоконагруженные приложения" Клепмана. Да, взаимодействие внутри микросервисной системы очевидно медленнее, чем вызовы внутри монолита, у всего есть цена. Но при правильно написанном коде, правильно выбранной архитектуре и правильно построенной инфраструктуре скорость всё ещё достаточно, чтобы отвечать на запросы за доли секунды. А для согласованности приходится применять подходы вроде паттерна "сага".
    Ответ написан
    Комментировать
  • Очень быстро лить в БД 1 млн. строк в секунду и настолько же быстро читать их. Как лучше осуществить?

    @Yury093
    Конечно может, вопрос в железе. И микроскопом можно забить гвоздь.
    Но на слова "хочу быстро вставлять и быстро читать потоком" так и хочется ответить "а зачем тебе БД?"

    Поэтому хотелось бы уточнить у автора: а вот кроме описанного "вставить миллион, считать миллион" - что предполагается делать с данными? Менять их построчно? Искать по какому-то ключу? это все надо? Если нет - я бы все же рекомендовал не использовать БД.

    Тут следует понимать что любая нормальная БД это [почти] всегда двойная запись на диск: вы пишите в таблицу И в лог базы данных. Именно поэтому файл или Kafka или иной MQ будет всегда быстрее.

    Ну а если БД все равно нужно - ну тогда BULK режимы вам в помощь. Обычно они используются для пакетной инициализирующей загрузки. В некоторых БД они на время своей работы могут отключать какие-то фичи или даже логирование в лог транзакций.
    ----------------------------
    Вообще по всем признакам в вашем случае идеальным будет вариант писать в MQ (RabbitMQ или Kafka или см аналоги), а уже из нее в БД. "Все так делают", по крайней мере в крупных компаниях это довольно типовое решение для подобных вашей задач. Причем БД в этой истории нужна только если вам потом нужно хранить и селектить. Если после первой операции данные вам более не нужны, либо нужен только бэкап, то БД не нужна - пишите в файл, пакуйте в zip (в энтерпрайзе - кидайте файлы в Hadoop в каком нибудь Parquet формате).
    Ответ написан
    1 комментарий
  • Что происходит на рынке труда в айти?

    ThunderCat
    @ThunderCat
    {PHP, MySql, HTML, JS, CSS} developer
    суть моего вопроса в следующем - как действительно выглядит этот самый старт для программиста, то есть чем вообще этот человек должен заниматься?
    Мне как человеку со школы "болевшего" айти сферой, сложно понять человека, который хочет стать программистом "по тому что там много платят" или "это модно"... По этому старт для программиста в моем понимании - много читать и пробовать все это реализовывать в коде. Все остальное дает иллюзию что вы что-то про это знаете, так как что-то про это слышали. Без реального опыта написания кода это все мусор и тлен. Причем код должен быть рабочим, сложным для вас на текущем этапе, и в идеале вызывать жгучее желание заниматься этим еще...

    Существует ли реальная проблема нагруженности рынка труда людьми с курсов? Они вообще устраиваются по новой специальности?
    Из реального опыта - до финала более-менее нормальных курсов, которые дают какие-то реальные основы, доходит ~10-15% студентов, остальные отваливаются, так как пришли за легким чтивом и халявой, а тут оказывается вкалывать нужно... Оставшиеся либо просто слишком настойчивы, но никак не пригодны, либо реально чего-то стоят, и там по Парето - 70/30 где то никаких/толковых. Вот эти 30 рано или поздно найдут работу.

    Заметили ли настоящие промышленные программисты какое-то изменение в своей работе после появления хайпа вокруг их профессии?
    настоящие промышленные программисты звучит как мускулистые работяги, мышью и клавой добывающие сталь в домнах ) Честно говоря - хз, ну есть какой-то нездоровый хайп вокруг айти, может чуть зарплаты в среднем выросли, но они и так достаточно серьезно растут с ростом скила програмера. Короче больше шума чем какой-то движухи...
    Ответ написан
    Комментировать
  • Что происходит на рынке труда в айти?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Вбейте в Google запрос "ИТ кадровый голод", в выдаче будет немало публикаций серьёзных изданий, объясняющих почему за лето зарплаты специалистов ИТ выросли на 30%. Например раз, два, три и четыре. Естественно, перспектива получать полмиллиона за сидение перед компом туманит головы обывателей и они ищут способ воплотить мечту. Естественно, что появилась целая куча инфоцыган, готовых окучивать эти наивные мечты. Только курсы никого не сделают программистом за полгода и старт в ИТ совсем не лёгкий.
    Ответ написан
    12 комментариев
  • Я так никогда не выучу React. Что это за ошибка?

    tsepen
    @tsepen
    Frontend developer
    Нельзя выучить Реакт не выучив Джаваскрипт, рекомендую начать с JS, иначе дальше тебя ждет еще очень много сюрпризов
    Ответ написан
    Комментировать
  • Почему на одних сервисах просят сначала email, а потом пароль, а на других сразу оба?

    @xfg
    Началось всё с того, что помимо стандартной формы входа на сайт также стали появляться кнопки входа через социальные сети. Например вы зарегистрировались на целевом сайте используя свой аккаунт на твиттере. Затем какое-то время не пользовались целевым сайтом, после чего вернулись и... Вы точно помните что у вас уже есть аккаунт на данном сайте, но вы не помните какой способ входа вы использовали. Перед вами с десяток различных кнопок. Какую из них нажимать? Думаю, история знакомая многим.

    Так вот в какой-то момент появилось исследование суть которого в том чтобы изменить форму входа таким образом, чтобы пользователю теперь было достаточно указать только email-адрес, а дальше система сама определит через какой провайдер был зарегистрирован пользователь на сайте с этим email-адресом и в зависимости от этого может либо отобразить пароль для ввода, сделать редирект на сайт провайдера для подтверждения входа или сразу аутентифицировать пользователя на целевом сайте, если пользователь уже авторизован и имеет необходимые разрешения для целевого сайта на сайте-провайдере (например на twitter.com).

    Таким образом это ничто иное как улучшение взаимодействия с пользователем. Но как и всё в мире имеет определенные недостатки. Например теперь можно узнать зарегистрирован ли определенный пользователь на определенном сайте зная лишь только его email адрес или номер телефона. То есть страдает конфиденциальность.

    Пример реализации можно увидеть на сайте yandex.ru.
    Ответ написан
    Комментировать
  • Как правильно ответить на вопрос работодателя о скорости верстки?

    sfi0zy
    @sfi0zy
    Creative frontend developer
    правильно

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

    с какой скоростью я верстаю

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

    Ну а еще - вопрос о скорости работы всегда зависит от текущего контекста. Мне встречались сайты, где нужно было что-то "пофиксить за 5 минут", но там черт ногу сломит, все зависит от всего, и уходили часы и дни, чтобы сделать какую-то мелочь, не сломав все остальное (а выбросить и переделать тоже нельзя). А видел сайты, где просто берешь и делаешь, ни о чем не думая. Понятно, что скорость выполнения "одинаковых" задач там различается в разы при одних и тех же моих умениях.

    как преподать себя

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

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Очевидно необходимы навыки дизайнера, верстальщика, фронтендера, бэкендера, знание SQL, умение администрировать СУБД, http-сервер и операционную систему, под которой они работают, а также в целом глубокое понимание принципов функционирования Web.
    Ответ написан
    2 комментария
  • Что порекомендуете renovate или snyk?

    есть задача автоматически обновлять пакеты в node.js и react репозиториев, используя CI/CD.

    Имхо, обновление пакетов не должно быть автоматическим, и тем более не должно быть частью CI/CD, тк приложение тестируется на вполне конкретных версиях пакетов, и вообще package-lock не для того придуман, чтобы его какая-то автоматика затирала.

    Ещё более-менее ок вариант - подобие dependabot, который делает PR с обновлёнными пакетами, который можно принять, если все тесты прошли.

    Так что renovate выглядит вполне нормальным решением для своевременных обновлений.
    Snyk же - это какое-то решение полного цикла, чтобы ещё до принятия PR проверять зависимости и всё такое.
    Ответ написан
    4 комментария