Ну это я так тонко намекнул, что им не рисовали усы.
Хотя у меня в голове сидит воспоминание, возможно ложное, о злодейском герое с маленькими чёрными усиками. Вроде на какого-то мафиози похож. Но возможно это вообще "Чёрный плащ" был, но и там я никого похожего не нашел.
Сначала убедимся, что разработчик смог правильно распарсить наш особенный формат данных.
Потом, мы понимаем, что он умеет сортировать поля.
Потом, он должен сдать 1й разряд по байтоукладчеству и посчитать хеш.
Потом, он должен правильно кроме кода еще и сформировать ответ.
Где-то забыл сохранить данные? Ну это мы твоей компании потом припомним!
Когда пишу интеграции с платежными шлюзами я просто логирую в БД весь трафик в текстовом виде.
И входящий и исходящий.
Спится спокойнее…
Я думаю, что большинство хороших прогеров не хотят перерастать в менеджеров.
Если же менеджер не был программистом, то программистам придется выпрашивать (в буквальном смысле) время на рефакторинг/тесты/песочницы.
Когда программист идет в менеджеры, это не профессиональный рост, это просто человек уперся в пололок в своей области.
Хорошему менеджеру проекта не необходим опыт разработки, он оперирует другими категориями. Это план выпуска фич, список срочных фиксов, зависимости между задачами, возможность замены разработчика на задаче и т.д.
Вы как программист, можете обосновать необходимость юнит-тестов или рефакторинга? Но так, чтобы было понятно, почему это будет полезно проекту?
Например, юнит-тесты конечному продукту не нужны. Но при последующей разработке пригодятся. Это фиксация функционала и другой разработчик (низко квалифицированный или не погруженный в задачу) не сломает бизнес логику выпустив фикс. Это максимально ранее обнаружение ошибок, т.е. экономит время разработчика.
К конечном итоге это выбор руководства проекта: выпустить фичу позже без технического долга или выпустить фичу быстрее и замедлить дальнейшее развитие.
Попробуйте обосновать рефакторинг. Например, отделение в бэкенде слоя доступа к данным (DAL)
Rollback — это всегда следствие смены ведущего сервера.
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Подготовка сервера к нагрузке — это целый комплекс мероприятий.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.
Что интересно, yandex-disk для Linux продолжает работать. Под Windows он отлично работает в wsl. Конечно, без иконки в трее.
Но я, на всякий случай, на https://syncthing.net перешёл. Мне надо только синхронизировать файлы на разных компах.
Правильно приоритИзация
self-hosted поддерживается?
Компенсатор гидроудара не правильно поставили.
Он должен стоять вертикально вверх или горизонтально во избежании мест с застаиванием воды.
Ну это я так тонко намекнул, что им не рисовали усы.
Хотя у меня в голове сидит воспоминание, возможно ложное, о злодейском герое с маленькими чёрными усиками. Вроде на какого-то мафиози похож. Но возможно это вообще "Чёрный плащ" был, но и там я никого похожего не нашел.
Гляньте хотя бы утиные истории, как пример хуманизации утки.
Как мне теперь развидеть волосы
во ртув клюве у утки?Десктопные кроссплатформенные парольные менеджеры которые хранят БД в файле:
* https://www.keepassx.org
* https://keepass.info
* https://keepassxc.org
Для мобилки тиких приложений больше.
Все работают поверх одного формата kdbx
Файл с паролями автоматически шифруется мастер паролем или локальным ключем.
Блоги перенесли...
Вот новые ссылки на оригинальный блог и его перевод
Какой именно встроенный механизм имеете ввиду?
Вот тут обещают до 64Gb.
Сначала убедимся, что разработчик смог правильно распарсить наш особенный формат данных.
Потом, мы понимаем, что он умеет сортировать поля.
Потом, он должен сдать 1й разряд по байтоукладчеству и посчитать хеш.
Потом, он должен правильно кроме кода еще и сформировать ответ.
Где-то забыл сохранить данные? Ну это мы твоей компании потом припомним!
Когда пишу интеграции с платежными шлюзами я просто логирую в БД весь трафик в текстовом виде.
И входящий и исходящий.
Спится спокойнее…
Если нет, то кажется, это уже достаточная защита от MITM.
Так вот в этом и вопрос: Зачем еще усложнять жизнь интегратору?
Просто добавьте атрибут async в элемент targets, NLog сам добавит асинхронные обертки.
Документация тут.
Когда программист идет в менеджеры, это не профессиональный рост, это просто человек уперся в пололок в своей области.
Хорошему менеджеру проекта не необходим опыт разработки, он оперирует другими категориями. Это план выпуска фич, список срочных фиксов, зависимости между задачами, возможность замены разработчика на задаче и т.д.
Вы как программист, можете обосновать необходимость юнит-тестов или рефакторинга? Но так, чтобы было понятно, почему это будет полезно проекту?
Например, юнит-тесты конечному продукту не нужны. Но при последующей разработке пригодятся. Это фиксация функционала и другой разработчик (низко квалифицированный или не погруженный в задачу) не сломает бизнес логику выпустив фикс. Это максимально ранее обнаружение ошибок, т.е. экономит время разработчика.
К конечном итоге это выбор руководства проекта: выпустить фичу позже без технического долга или выпустить фичу быстрее и замедлить дальнейшее развитие.
Попробуйте обосновать рефакторинг. Например, отделение в бэкенде слоя доступа к данным (DAL)
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.