Сначала убедимся, что разработчик смог правильно распарсить наш особенный формат данных.
Потом, мы понимаем, что он умеет сортировать поля.
Потом, он должен сдать 1й разряд по байтоукладчеству и посчитать хеш.
Потом, он должен правильно кроме кода еще и сформировать ответ.
Где-то забыл сохранить данные? Ну это мы твоей компании потом припомним!
Когда пишу интеграции с платежными шлюзами я просто логирую в БД весь трафик в текстовом виде.
И входящий и исходящий.
Спится спокойнее…
Я думаю, что большинство хороших прогеров не хотят перерастать в менеджеров.
Если же менеджер не был программистом, то программистам придется выпрашивать (в буквальном смысле) время на рефакторинг/тесты/песочницы.
Когда программист идет в менеджеры, это не профессиональный рост, это просто человек уперся в пололок в своей области.
Хорошему менеджеру проекта не необходим опыт разработки, он оперирует другими категориями. Это план выпуска фич, список срочных фиксов, зависимости между задачами, возможность замены разработчика на задаче и т.д.
Вы как программист, можете обосновать необходимость юнит-тестов или рефакторинга? Но так, чтобы было понятно, почему это будет полезно проекту?
Например, юнит-тесты конечному продукту не нужны. Но при последующей разработке пригодятся. Это фиксация функционала и другой разработчик (низко квалифицированный или не погруженный в задачу) не сломает бизнес логику выпустив фикс. Это максимально ранее обнаружение ошибок, т.е. экономит время разработчика.
К конечном итоге это выбор руководства проекта: выпустить фичу позже без технического долга или выпустить фичу быстрее и замедлить дальнейшее развитие.
Попробуйте обосновать рефакторинг. Например, отделение в бэкенде слоя доступа к данным (DAL)
Rollback — это всегда следствие смены ведущего сервера.
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Подготовка сервера к нагрузке — это целый комплекс мероприятий.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.
Я реализовал чуть более продвинутое решение.
Пробовал использовать V-USB но это тупиковый путь.
Использовал контроллер ATxmega128A4-AU в нем есть аппаратный USB
Для управления использовал LUFA (https://github.com/abcminiuser/lufa.git)
Клавиатура на 10 кнопок, 2x7segment LED индикатор, хранение на MicroSD в FAT32, эмуляция MassStorageDevice для управления паролями
свободно еще половина контроллера
Никогда не держите квадрокоптер так как на первой фотке!
Понятно, что он выключен, винты маломощные, но пожалуйста не показывайте такие фотки. Это как техника безопасности со стрелковым оружием, должно запоминаться на уровне рефлексов — такие винты (не пенопластовые) и пальцы не совместимы.
Блоги перенесли...
Вот новые ссылки на оригинальный блог и его перевод
Какой именно встроенный механизм имеете ввиду?
Вот тут обещают до 64Gb.
Сначала убедимся, что разработчик смог правильно распарсить наш особенный формат данных.
Потом, мы понимаем, что он умеет сортировать поля.
Потом, он должен сдать 1й разряд по байтоукладчеству и посчитать хеш.
Потом, он должен правильно кроме кода еще и сформировать ответ.
Где-то забыл сохранить данные? Ну это мы твоей компании потом припомним!
Когда пишу интеграции с платежными шлюзами я просто логирую в БД весь трафик в текстовом виде.
И входящий и исходящий.
Спится спокойнее…
Если нет, то кажется, это уже достаточная защита от MITM.
Так вот в этом и вопрос: Зачем еще усложнять жизнь интегратору?
Просто добавьте атрибут async в элемент targets, NLog сам добавит асинхронные обертки.
Документация тут.
Когда программист идет в менеджеры, это не профессиональный рост, это просто человек уперся в пололок в своей области.
Хорошему менеджеру проекта не необходим опыт разработки, он оперирует другими категориями. Это план выпуска фич, список срочных фиксов, зависимости между задачами, возможность замены разработчика на задаче и т.д.
Вы как программист, можете обосновать необходимость юнит-тестов или рефакторинга? Но так, чтобы было понятно, почему это будет полезно проекту?
Например, юнит-тесты конечному продукту не нужны. Но при последующей разработке пригодятся. Это фиксация функционала и другой разработчик (низко квалифицированный или не погруженный в задачу) не сломает бизнес логику выпустив фикс. Это максимально ранее обнаружение ошибок, т.е. экономит время разработчика.
К конечном итоге это выбор руководства проекта: выпустить фичу позже без технического долга или выпустить фичу быстрее и замедлить дальнейшее развитие.
Попробуйте обосновать рефакторинг. Например, отделение в бэкенде слоя доступа к данным (DAL)
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.
Пробовал использовать V-USB но это тупиковый путь.
Использовал контроллер ATxmega128A4-AU в нем есть аппаратный USB
Для управления использовал LUFA (https://github.com/abcminiuser/lufa.git)
Клавиатура на 10 кнопок, 2x7segment LED индикатор, хранение на MicroSD в FAT32, эмуляция MassStorageDevice для управления паролями
свободно еще половина контроллера
Понятно, что он выключен, винты маломощные, но пожалуйста не показывайте такие фотки. Это как техника безопасности со стрелковым оружием, должно запоминаться на уровне рефлексов — такие винты (не пенопластовые) и пальцы не совместимы.
«mobile first сервис», а ну тогда все в порядке, извините.
В описаниях тарифов все ссылки ведут на главную страницу. Там так везде?
Чего то страшно мне ваше приложение ставить.
Например, тут в комментах будет собран список для: «Смерть… от естественных причин, но в неподходящее время.»
В варианте для AVR, он основан на нестабильности частоты RC генератора watchdog таймера по отношению к генератору тактовой частоты на кварце.
Вот пример реализации: gist.github.com/endolith/2568571