У нас на проекте подсчет ведется в человеко-днях. Можно перевести все на человеко-часы, подобные схемы есть. В нашей команде 20+ человек, а спринт длится месяц, поэтому проще посчитать человеко-дни (значения обычно на уровне 100+), а не человек-часы (их тогда будет 1000+).
Как правило, такого рода задачи — это составляющие более крупной задачи. В нашем бэклоге задач меньше 1 человеко-дня нет.
В целом этот вопрос на каждом проекте решается индивидуально в зависимости от того, кто будет пользоваться инструментом, насколько это удобно, какие фичи нужны конкретно, какие инструменты принято было использовать исторически. Некоторые считают Postman более удобным в использовании и установке, поэтому и выбор даже просто из-за этого фактора может лечь на него.
У нас на проекте более 300 запросов, поделенных на коллекции по продуктам, к которым запросы составлялись, и проблем с прогрузкой не возникало)
Документацию ведет и актуализирует один специалист, в нашем случае аналитик. На эту работу выделяется отдельная задача в спринте.
Выгружаем в GitLab, шарим ссылку на всех заинтересованных лиц.
У нас есть два варианта. Первый — инструкции по использованию коллекций для тех, у кого возникли по этому моменту вопросы. Второй — если нужно какой-то новый скрипт добавить и возникли затруднения, коллеги обращаются с вопросами к тем, у кого опыта в кодинге больше. Например, наш аналитик обращается за помощью к команде разработки или SDET-специалистам.
Основной смысл перехода в значительном снижении рисков. Основной риск в облаке — внезапное прекращение работы. Риск в on-premise — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака
Спасибо за ваше дополнение. Вы правы относительно ProofOfConcept и простых решений. Справедливости ради, это замечание нашло свое отражение в нашей третьей статье о Design Api First (https://habr.com/ru/companies/simbirsoft/articles/746020/). Рациональность и применимость той или иной методологии всегда стоит рассматривать в контексте вашей ситуации. Для нас ее применение обосновано как минимум по двум причинам: разработка итеративна — в контракт вносятся изменения, команды Backend и Frontend работают параллельно
Согласны с тем, что лучше писать указывать тип формата данных на всякий случай ?
Наши справочники обновляются очень редко. То есть, быстрее будет сделать frontend- и backend- части, тестирование и обучение для бизнеса, чем просто прислать excel-документ (более доступный для клиента) и далее написать миграцию на несколько строчек?
Если все равно придется вручную проверять, что лежит в БД, зачем тогда нужен еще один инструмент?
Вероятнее всего, реализация возможности запуска 16-битных приложений в новейших версиях Windows слишком трудозатратна и бесперспективна с коммерческой точки зрения. Ресурсов требуется море, а профит оценят только небольшое число энтузиастов. Все-таки Microsoft — коммерческая организация, а Windows — это не open-source проект, поддерживаемый сообществом.
Да — но данная конструкция всего лишь отключает искажение имен (Name Mangling) для С++ кода (в С, напомню, ничего подобного нет). Но ничего не говорит о Calling Convention, то есть о технических особенностях вызова (cdecl это или скажем stdcall)
По умолчанию для компиляторов Microsoft и для ABI x64 — да. Но тут речь не про частности, а про общий случай - чтоб и MSVC "переварил" и MinGW и прочие Clang'и. А для этого нужно использовать __cdecl соглашение о вызовах
Тут речь не про приложения, а про целевую платформу. Цитата Microsoft (https://learn.microsoft.com/ru-ru/windows/win32/winprog64/running-32-bit-applications) отсюда: "Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений windows. Основная причина заключается в том, что дескриптор имеет 32 значимых бита в 64-разрядной версии Windows. Таким образом, дескрипторы не могут быть усечены и переданы в 16-разрядные приложения без потери данных. Попытки запуска 16-разрядных приложений завершаются сбоем со следующей ошибкой: ERROR_BAD_EXE_FORMAT."
Речь идет не о готовой плюсовой либе, а о расширении функциональности через готовое решение, написанное на С++. Берем этот код, если нужно — вносим необходимые изменения, собираем из него динамическую библиотеку и подключаем к нужному нам проекту. В статье мы пошагово расписали, как это сделать применительно к Java и Python. Про боль и страдания — вопрос субъективный ?
Под началом работы на проекте мы подразумеваем этап написания ТЗ, поэтому фактически контрольные точки мы определяем до старта разработки. И ревью архитектуры проводит архитектор не из команды проекта, чтобы избежать "замыленности взгляда".
Часть пунктов из вашего списка как раз у нас в выводах.
Про плавную раскатку согласна. Но не всегда ее можно провести. И даже не всегда есть возможность отказаться от релиза в выходной. Есть разные продукты и требования бизнеса. Есть продукты, когда релиз проводится только в выходной и ночью. Потому что есть определенные требования к доступности сервиса.
То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.
Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.
Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.
Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку. Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании. Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение. Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.
Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.
Ваш посыл в целом здравый. Но все же отметать надежность на ранних этапах развития продукта может привести к тому, что он не “взлетит”. Поэтому лучше искать золотую середину между скоростью и надежностью.
У нас на проекте подсчет ведется в человеко-днях. Можно перевести все на человеко-часы, подобные схемы есть. В нашей команде 20+ человек, а спринт длится месяц, поэтому проще посчитать человеко-дни (значения обычно на уровне 100+), а не человек-часы (их тогда будет 1000+).
Как правило, такого рода задачи — это составляющие более крупной задачи. В нашем бэклоге задач меньше 1 человеко-дня нет.
Описание разницы Swagger и Postman тянет на отдельную статью (например,
здесь https://apidog.com/articles/postman-vs-swagger/#limitations-of-postman-and-swagger).
В целом этот вопрос на каждом проекте решается индивидуально в зависимости от того, кто будет пользоваться инструментом, насколько это удобно, какие фичи нужны конкретно, какие инструменты принято было использовать исторически. Некоторые считают Postman более удобным в использовании и установке, поэтому и выбор даже просто из-за этого фактора может лечь на него.
У нас на проекте более 300 запросов, поделенных на коллекции по продуктам, к которым запросы составлялись, и проблем с прогрузкой не возникало)
Спасибо за отклик!
Документацию ведет и актуализирует один специалист, в нашем случае аналитик. На эту работу выделяется отдельная задача в спринте.
Выгружаем в GitLab, шарим ссылку на всех заинтересованных лиц.
У нас есть два варианта. Первый — инструкции по использованию коллекций для тех, у кого возникли по этому моменту вопросы. Второй — если нужно какой-то новый скрипт добавить и возникли затруднения, коллеги обращаются с вопросами к тем, у кого опыта в кодинге больше. Например, наш аналитик обращается за помощью к команде разработки или SDET-специалистам.
Спасибо за внимательность, поправили
Основной смысл перехода в значительном снижении рисков. Основной риск в облаке — внезапное прекращение работы. Риск в on-premise — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака
Спасибо за ваше дополнение. Вы правы относительно ProofOfConcept и простых решений. Справедливости ради, это замечание нашло свое отражение в нашей третьей статье о Design Api First (https://habr.com/ru/companies/simbirsoft/articles/746020/). Рациональность и применимость той или иной методологии всегда стоит рассматривать в контексте вашей ситуации. Для нас ее применение обосновано как минимум по двум причинам: разработка итеративна — в контракт вносятся изменения, команды Backend и Frontend работают параллельно
Согласны с тем, что лучше писать указывать тип формата данных на всякий случай ?
Наши справочники обновляются очень редко. То есть, быстрее будет сделать frontend- и backend- части, тестирование и обучение для бизнеса, чем просто прислать excel-документ (более доступный для клиента) и далее написать миграцию на несколько строчек?
Если все равно придется вручную проверять, что лежит в БД, зачем тогда нужен еще один инструмент?
Liquibase — это как Git для структуры БД. Гораздо меньше работы ляжет на плечи DevOps-разработчиков при обновлении и откате инстансов приложений.
Что существенно поменяется, если взять, например, 10м? :)
В нашем случае речь идет о миграции именно справочника, а не данных. Сам Liquibase
поддерживает эту функцию, что сильно облегчает развертывание.
Конечно, есть — он и используется. Ведь механизм FFI (Foreign function interface) и создан для интеграции между языками https://ps-group.github.io/compilers/backend_ffi
Вероятнее всего, реализация возможности запуска 16-битных приложений в новейших версиях Windows слишком трудозатратна и бесперспективна с коммерческой точки зрения. Ресурсов требуется море, а профит оценят только небольшое число энтузиастов. Все-таки Microsoft — коммерческая организация, а Windows — это не open-source проект, поддерживаемый сообществом.
Да — но данная конструкция всего лишь отключает искажение имен (Name Mangling) для С++ кода (в С, напомню, ничего подобного нет). Но ничего не говорит о Calling Convention, то есть о технических особенностях вызова (cdecl это или скажем stdcall)
По умолчанию для компиляторов Microsoft и для ABI x64 — да. Но тут речь не про частности, а про общий случай - чтоб и MSVC "переварил" и MinGW и прочие Clang'и. А для этого нужно использовать __cdecl соглашение о вызовах
Тут речь не про приложения, а про целевую платформу. Цитата Microsoft (https://learn.microsoft.com/ru-ru/windows/win32/winprog64/running-32-bit-applications) отсюда: "Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений windows. Основная причина заключается в том, что дескриптор имеет 32 значимых бита в 64-разрядной версии Windows. Таким образом, дескрипторы не могут быть усечены и переданы в 16-разрядные приложения без потери данных. Попытки запуска 16-разрядных приложений завершаются сбоем со следующей ошибкой: ERROR_BAD_EXE_FORMAT."
Речь идет не о готовой плюсовой либе, а о расширении функциональности через готовое решение, написанное на С++. Берем этот код, если нужно — вносим необходимые изменения, собираем из него динамическую библиотеку и подключаем к нужному нам проекту. В статье мы пошагово расписали, как это сделать применительно к Java и Python. Про боль и страдания — вопрос субъективный ?
Под началом работы на проекте мы подразумеваем этап написания ТЗ, поэтому фактически контрольные точки мы определяем до старта разработки. И ревью архитектуры проводит архитектор не из команды проекта, чтобы избежать "замыленности взгляда".
Часть пунктов из вашего списка как раз у нас в выводах.
Про плавную раскатку согласна. Но не всегда ее можно провести. И даже не всегда есть возможность отказаться от релиза в выходной. Есть разные продукты и требования бизнеса. Есть продукты, когда релиз проводится только в выходной и ночью. Потому что есть определенные требования к доступности сервиса.
То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.
Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.
Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.
Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку.
Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании.
Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение.
Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.
Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.
Ваш посыл в целом здравый. Но все же отметать надежность на ранних этапах развития продукта может привести к тому, что он не “взлетит”.
Поэтому лучше искать золотую середину между скоростью и надежностью.
Спасибо за интерес и справедливое замечание. Расширили раздел про auto-accessor