видимость бурной деятельности если просто решить проблему, то бюджеты не освоить. поэтому надо сделать из мухи слона и потом его героически победить, а затраты на победу, да кого они волнуют, победителей не судят.
возможно борьба с фродом это не единственная задача этих систем, возможно есть какие то не публичные опции которым необходимо больше информации чем нужно для борьбы с фродом...
поэтому я и сказал что немного не соглашусь, что в ваших словах есть тоже доля истины и проблему что вы затронули она реальна и приходится к ее решению адаптироваться.
мой опыт на большинстве проектов:
Добавляя миграцию приходится открывать файл с сотнями миграций и скролить вниз чтобы найти файлик, такое делается ~10 раз в месяц, мне такое не нравится.
Когда надо поднять тестовый стенд чтобы протестировать задачу, каждый раз выполнять сотни миграций банально долго, можно конечно брать структуру с прода, а потом поверх нее катить миграции и потом заполнять тестовыми данными, но иногда проще на прод не лазить и запустится из миграций, такие операции еще чаще бывают в месяц.
Вот ситуации когда надо полазить в старом коде они бывают не так часто, по крайне мере по моему опыту может у других другой опыт, несколько раз в год, причем редко надо откатываться сильно далеко (более одного года назад).
Новый разработчик на проекте, это вы описали, такое бывает у всех по разному но пусть будет ~1 в квартал (3 месяца)
исходя из таких вводных я пришел к выводу для проектов (у вас может быть свой опыт и свои выводы, это ок). Схлопывать транзакции в один init дамп периодически, по наполнению папки с миграциями большим числом файлов, примерно раз в квартал или раз в год.
При этом я вполне спокойно отношусь к тем кто не объединяет миграции, объединение миграций это инструмент, а не silver bullet, поэтому его надо применять к месту, кому то он может не подходить.
Миграции нужны чтобы обновлять структуру данных к актуальному состоянию.
Что касается приведенного вами случая из него можно легко выкрутится, когда вы переключились на старый комит у вас там есть какие то миграции, просто они не позволят откатить текущую бд, но никто вам не запрещает дропнуть базу и накатить структуру снова к тому состоянию что в репозитории
И если он юридически ничего не нарушил при этом, то юридически к нему и вопросов как бы нет.
тут не в юридическом плане были вопросы, а сочувствовать кому то или нет это индивидуальный и каждый решает сам кому сочувствовать, так что он вполне может не сочувствовать и нет юридического закона обязывающего его это делать.
в остальном полность согласен с вами, насчет рисков и представлений о програмистах.
ну это понятно, что план выглядит красиво, но всегда есть "нюансы"
понятно что если ты сеньор разработкчик/devops/менеджер то тебе выгодней просто работать чем все эти льготы выбивать и тратить на это свое время, но например если дома есть жена домохозяйка, то почему бы ее не отправить штурмовать круги бюрократического ада, или например любому без работному это вполне возможность что то начать делать.
я ип с 2020 года по текущую дату и у меня было ип еще с 2012 года по 2015
перед открытием ип в 2020 году (когда были самозанятые) я делал табличку для себя в экселе для просчета выгодности того или иного способа налого облажения, также я смотрел региональные налоговые льготы у себя в регионе, даже без льгот, для большинства случаев ип + патент или ооо на упрощенке + патент выгодней и удобней, разница в том что на ип надо чуть больше отчетности, а именно:
Декларация раз в год за упрощенку
Заявление на патент каждый год
Оплата в фонды желательно по квартально, чтобы в этом квартале можно было списать эти деньги, ну или 1 и 4 квартал (при патенте на год, 1/3 оплачивается в первые 90 дней - 1 квартал, а оставшиеся 2/3 оплачиваются до конца действия патента - можно оплатить в 4 квартале) сумарно ~40к в год
Заявление на уменьшение (тоесть вы оплачиваете в фонды, а потом вместо оплаты за патент подаете заявление на уменьшение суммы оплаты до 0) 5.Открытие расчетного счета ну и оплата его содержимого примерно 500 руб (есть тарифы где если нет переводов 0 рублей)
Ведение КУДИР для усн и КУДИР для патента (есть сервисы, если оборот только по расчетному счету вообще нет проблем)
Этот вариант становится выгодным если у вас годовой оборот свыше 240к (это по 20к в месяц примерно) я думаю что можно выделить время и сэкономить, все документы подаются электронно, эцп выдается бесплатно (нужно один раз съездить за ней в налоговую, далее продлевается без визитов).
У самозанятого есть плюсы
Если оборот менее 240к в год, он становится выгодней (обязательные платежи 40к у ип от них никак не уйти)
Отчетности меньше, нужно лишь оплаты отразить
на этом плюсы самозанятости заканчиваются и начинаются минусы, самозанятость выгодней ГПХ.
Самое простое это сделать другую прописку, деятельность ИП считается по месту прописки автоматически, но да можно регнуть ИП в одном месте(мск), а патент получить в регионе в котором ведётся деятельность, просто это чуть сложней оформлять на бумаге
Около 160кк это лимит для усн, для патента лимит 60кк вроде(он меньше чем у УСН)
Про доп 1% с дохода да оно есть, на патенте используется потенциальный доход вроде, он кроме мск редко где превышает 300к, поэтому на патенте его платить нет необходимости.
В большинстве случаев ИП выгодней чем самозанятость, исключения разве что очень маленькие обороты, менее 20к в месяц (суммы с которой удерживаются суммы в ПФР, фомс)
ах да еще забыл сказать, что в некоторых регионах при открытие ип доступны налоговые каникулы 0, в некоторых регионах они доступны и не при первом открытие ип (можно закрывать и снова открывать) это надо смотреть региональные программы поддержки малого бизнеса, помимо налоговых каникул поддержка может быть осуществлена целевым финансированием, план примерно такой:
Встаете на учет что вы безработный
Ездите в несколько организаций по направлениям (3 штуки вроде) получаете отказы.
Говорите я хочу открыть бизнес поддержите меня (в регионах есть поддержка)
Вы готовите бизнес план
Защищаете бизнес план (им выгодно чтобы уменьшить число без работных), вам даже госпошлину за открытие ип возможно не придется платить
На ваш бизнес план выделяют деньги (которые не надо возвращать) их надо тратить целевым способом, например в бизнес плане можно указать что вам нужен ноутбук, 50% стоймости ноутбука будет за ваш счет, 50% с этих денег, с этих же денег можно оплачивать аренду офиса или коворкинга и прочего (главное все это внести в бизнес план), надо лишь отчитываться чеками и прочим за потраченные деньги.
ПРОФИТ!!!
причем такую штуку можно подавать и на следующий год...
тут можно многое придумать, например открыть такси и 50% машины купить за счет гранта такого, минус один надо бегать по этим бюджетным учереждениям, очереди, составления бумажек, но и профит можно получить, с точки зрения айти это копейки.
такие штуки это интересный опыт и возможно написание отдельных статей на хабре, знаю что некоторые таким образом открывали фотоателье, покупали ноутбук macbook за 50% и фотоаппарат за 50%, также открывали такси, чтобы купить логан за пол цены и еще другие сферы сельское хозяйство например, просто это не совсем тематика хабра, я лично такое не проходил, но есть те кто подобное проходили и "работают" таким образом.
Итог - Фрилансерам работать получив статус самозанятого , на сегодняшний день , на территории РФ - выгодней всего.
абсолютно нет вы платите налог 6% с дохода максимально возможный доход не помню точно около 2.4кк (по 200к в месяц примерно) 2.4 * 0,06 = 0,144кк налогов. (или 144к)
если взять ип на патенте, то сумма всяких взносов ~40k на эту сумму можно уменьшить стоймость патента, в МСК он около 60к или 80к (надо доплатить 60 - 40 или 80 - 40), в большинстве других городов он стоит меньше 40к, можно например прописку сделать НЕ МСК (первый раз когда не мск прописка лучше :) ) плюс сюда доп расходы в виде оплаты расчетного счета пусть будет 500 руб в месяц, 12 * 500 = 6к Итого ваши расходы будут 46к причем патент будет работать до 60кк а самозанятый оборот должен иметь до ~2,4кк - мысль в том что хорошие специалисты скорей всего превысят 2,4кк оборота в год
Почитал комменты и ваш пост и замечаю что вы комментариями в коде пытаетесь заменить документацию, комментарии != документация
Хорошо если есть хорошая документация, а также в коде к нужным местам комментарии, но что будет плохого если будет документация, рабочий код, но он будет без комментариев?
По мне ничего страшного, значит комментарии не так сильно нужны для документации.
Другой пример пример где javadoc комментарии излишни если они не привносят никакой информации, например:
/**
* @return int
*/
int main()
Какой смысл тут в комментарии ?
Только приведенный пример не значит что комментарии не нужны, это значит что их как и многое надо использовать к месту.
как то я слишком расплывчато написал, попробую кратко по пунктом сумировать
вместо data-testid можно, а возможно даже лучше использовать стандартный id
пользовательские атрибуты (data-*) нужно использовать по назначению там где нет стандартных.
для того чтобы изолировать тесты от структуры документа и не использовать селекторы в тестах можно использовать page object, но это надо далеко не всем
использование пользовательских атрибутов это не значит что вы отказались от css селекторов.
так кто вам гарантирует что при изменение верстки тот кто верстал не посносил data-testid ?
тесты на то и тесты чтобы не заливать то что не проходит тесты, поэтому тот кто поменяет верстку, будет обновлять и page object, тесты ему напомнят что упало и на что обратить внимания, для этого они и пишутся.
например пусть была некая колонка с балансом в профиле пользователя, а после редизайна она перехала куда то в другое место, на другую страницу (мой баланс например и там текущий баланс и операции пополнения и расходов) как вы ее будете находить не меняя тестов ? будете оставлять колонку на баланс в профиле с display: none ? (костылище) как в этом случае мне поможет подход озвученный вами ?
тоесть при подобном кейсе в моем варианте.
Разработчик обновляет верстку (редизайн и тд) сфокусировавшись на этом.
Запускает тесты чтобы заметить регресс.
Исправляет регресс у упавших тестов.
MR
В вашем случае на первом этапе помимо фокусирования на задаче, разработчик еще будет смотреть data-* атрибуты и где они используются в тестах, получится он на первом шаге будет делать еще и второй и третий этапы.
где тут отказ от xpath/css селекторов ?
ваше предложение сводится к тому что используйте пользовательские атрибуты в xpath/css селекторах в тестах вместо class/id/tag.
Вот я не согласен на "вместо" я считаю что надо использовать там где возможно стандартные селекторы основанные на tag/class/id, а где необходимо можно добавлять и пользовательские атрибуты, но не строить тестирование только вокруг пользовательских атрибутов.
Чем предложенный вами data-testid отличается от обычного id ? Почему человеку надо вместо id использовать data-testid ?
Идентификатор (называемый также «ID селектор») определяет уникальное имя элемента, которое используется для изменения его стиля и обращения к нему через скрипты.
я даже выделил важное в цитате, как раз то как вы собираетесь использовать его.
просмотрел статью по диаганали, по озвученным проблемам уже давно существует решение в виде page object, отсюда в тестах не используется xpath, а используется page object в котором уже скрыта (инкапсулирована) работа с xpath.
Итог: не обязательно добавлять data-testid можно использовать обычные id, class, tag если они есть, вопрос именования это отдельная тема, не будем спорить нужен ли БЭМ или альтернативы.
Добавляя data-testid мы не перестаем использовать xpath, мы вместо использование классов, тэгов, id. Начинаем использовать пользовательские атрибуты.
я знаю разницу между swarm и compose, но спасибо что напомнили.
я говорил что вместо использования docker-compose утилиты, можно сделать
docker swarm init
и далее брать текущие docker-compose.yml файлики и запускать примерно так
docker stack deploy -c ./docker-compose.yml test
и все будет работать так как везде docker-compose.yml версии 3 (тут нет специфичных вещей)
при этом разница в том что человек
Не доустанавливал docker-compose утилиту (в некоторых ос ее надо доставлять дополнительно)
Не изучал параметры утилиты docker-compose (вполне достаточно docker swarm, stack и тд того что идет из коробки)
Плюсом получил возможность примитивную возможность объединять в кластер, которой обычно достаточно ОЧЕНЬ многим (некоторые прод держат на docker-compose и если работает и их все устрайвает то почему бы и не ДА ?)
поэтому если человек ищет инструмент для запуска окружения, я бы в 2023 году советовал в начале использовать стандартный (docker swarm вместо docker-compose), а уже потом он сам выберет нужен ему k8s или k3s или что либо другое.
возможности утилиты docker-compose с лихвой перекрываются docker swarm mode и рациональней начинать изучение с нее в 2023 году (как и годами раньше), раньше году в 2015 когда не было swarm mode да docker-compose было полезно и удобно и некоторые по привычки могут его использовать и дальше.
даже не представляю зачем сейчас изучать docker-compose если можно можно брать эти же самые docker-compose.yml (любые где версия 3.х) и запускать их в docker swarm
docker swarm считается заброшенной, а docker-compose это вообще древний рудимент
возможно я набросил слишком холиварно, но docker swarm по всем параметрам обходит docker-compose, единственный минус это не подеррживает версию ниже 3, во второй там были свои "фишки".
я в свое время тоже пришел к деревьям, даже хотел сделать небольшой веб интерфейс для управления, но как всегда руки не дошли.
Моя идея была в том чтобы была мотивация делать дела из нижнего списка, чтобы видеть верхне уровневую цель, например: Основная цель поработить человечество, ее блокирует построение звезды смерти, ее блокирует необходимость создания стабильного ядра звезды смерти (вспоминаем фильм :) ), ее блокирует отсутвующий специалист, ее блокирует конкретная задача: Позвонить Дарт вейдору в понедельник для рекрутинга архитектора.
Вот когда у тебя список дел состоит из задач конкретных при этом всегда видно глобальную цель и при этом видно цепочку того что оно блокирует это лично меня мотивирует ее быстрее сделать, чем если бы просто была задача: Обсудить с Дарт Ведером вакансию архитектора, какого архитектора ? зачем ? что мне это даст ? и соответственно завершая такую мелкую задачку можно сразу показывать что она может разблокировать и фокусироваться на других задачах, также очень удобно одновременно указывать все известные блокеры которые можно делать паралельно.
Применяя такой подход в реальной жизни я гораздо быстрей достигал поставленных целей.
я бы добавил сюда еще то что тестировщика надо как можно раньше подключать к ознакомлению фитчи, от поставноки задачи аналитиком, чтобы он понимал какой именно результат нужен в итоге.
В идеале аналитик = тестировщик, чтобы кто ставил задачи он их и принимал.
синий :)
как кит на лого
а потом еще можно каждый год отмечать
Можно
Одна команда в консоле
Которую можно за биндить на клавишу
не так давно открыл для себя сериал halt and catch прямо очень понравился, дух олдскула и стартапов, рекомендую он мало известен (брилиант)
есть еще силиконовая долина сериал, странно что нет в списке
еще классный сериал это the scene первый сезон в частности, но он очень специфический, далеко не всем зайдет
классически Hackers, 1995 года с молодой Джоли
it crowd сериал, с 2006 года, первые сезоны понравись.
их вообще много, хабр вроде не кинопоиск :)
я много смотрел, все уж и не вспомнить
видимость бурной деятельности
если просто решить проблему, то бюджеты не освоить.
поэтому надо сделать из мухи слона и потом его героически победить, а затраты на победу, да кого они волнуют, победителей не судят.
возможно борьба с фродом это не единственная задача этих систем, возможно есть какие то не публичные опции которым необходимо больше информации чем нужно для борьбы с фродом...
поэтому я и сказал что немного не соглашусь, что в ваших словах есть тоже доля истины и проблему что вы затронули она реальна и приходится к ее решению адаптироваться.
мой опыт на большинстве проектов:
Добавляя миграцию приходится открывать файл с сотнями миграций и скролить вниз чтобы найти файлик, такое делается ~10 раз в месяц, мне такое не нравится.
Когда надо поднять тестовый стенд чтобы протестировать задачу, каждый раз выполнять сотни миграций банально долго, можно конечно брать структуру с прода, а потом поверх нее катить миграции и потом заполнять тестовыми данными, но иногда проще на прод не лазить и запустится из миграций, такие операции еще чаще бывают в месяц.
Вот ситуации когда надо полазить в старом коде они бывают не так часто, по крайне мере по моему опыту может у других другой опыт, несколько раз в год, причем редко надо откатываться сильно далеко (более одного года назад).
Новый разработчик на проекте, это вы описали, такое бывает у всех по разному но пусть будет ~1 в квартал (3 месяца)
исходя из таких вводных я пришел к выводу для проектов (у вас может быть свой опыт и свои выводы, это ок).
Схлопывать транзакции в один init дамп периодически, по наполнению папки с миграциями большим числом файлов, примерно раз в квартал или раз в год.
При этом я вполне спокойно отношусь к тем кто не объединяет миграции, объединение миграций это инструмент, а не silver bullet, поэтому его надо применять к месту, кому то он может не подходить.
Немного не соглашусь
Миграции нужны чтобы обновлять структуру данных к актуальному состоянию.
Что касается приведенного вами случая из него можно легко выкрутится, когда вы переключились на старый комит у вас там есть какие то миграции, просто они не позволят откатить текущую бд, но никто вам не запрещает дропнуть базу и накатить структуру снова к тому состоянию что в репозитории
тут не в юридическом плане были вопросы, а сочувствовать кому то или нет это индивидуальный и каждый решает сам кому сочувствовать, так что он вполне может не сочувствовать и нет юридического закона обязывающего его это делать.
в остальном полность согласен с вами, насчет рисков и представлений о програмистах.
ну это понятно, что план выглядит красиво, но всегда есть "нюансы"
понятно что если ты сеньор разработкчик/devops/менеджер то тебе выгодней просто работать чем все эти льготы выбивать и тратить на это свое время, но например если дома есть жена домохозяйка, то почему бы ее не отправить штурмовать круги бюрократического ада, или например любому без работному это вполне возможность что то начать делать.
я ип с 2020 года по текущую дату и у меня было ип еще с 2012 года по 2015
перед открытием ип в 2020 году (когда были самозанятые) я делал табличку для себя в экселе для просчета выгодности того или иного способа налого облажения, также я смотрел региональные налоговые льготы у себя в регионе, даже без льгот, для большинства случаев ип + патент или ооо на упрощенке + патент выгодней и удобней, разница в том что на ип надо чуть больше отчетности, а именно:
Декларация раз в год за упрощенку
Заявление на патент каждый год
Оплата в фонды желательно по квартально, чтобы в этом квартале можно было списать эти деньги, ну или 1 и 4 квартал (при патенте на год, 1/3 оплачивается в первые 90 дней - 1 квартал, а оставшиеся 2/3 оплачиваются до конца действия патента - можно оплатить в 4 квартале) сумарно ~40к в год
Заявление на уменьшение (тоесть вы оплачиваете в фонды, а потом вместо оплаты за патент подаете заявление на уменьшение суммы оплаты до 0) 5.Открытие расчетного счета ну и оплата его содержимого примерно 500 руб (есть тарифы где если нет переводов 0 рублей)
Ведение КУДИР для усн и КУДИР для патента (есть сервисы, если оборот только по расчетному счету вообще нет проблем)
Этот вариант становится выгодным если у вас годовой оборот свыше 240к (это по 20к в месяц примерно)
я думаю что можно выделить время и сэкономить, все документы подаются электронно, эцп выдается бесплатно (нужно один раз съездить за ней в налоговую, далее продлевается без визитов).
У самозанятого есть плюсы
Если оборот менее 240к в год, он становится выгодней (обязательные платежи 40к у ип от них никак не уйти)
Отчетности меньше, нужно лишь оплаты отразить
на этом плюсы самозанятости заканчиваются и начинаются минусы, самозанятость выгодней ГПХ.
Да вы правильно пишите
Самое простое это сделать другую прописку, деятельность ИП считается по месту прописки автоматически, но да можно регнуть ИП в одном месте(мск), а патент получить в регионе в котором ведётся деятельность, просто это чуть сложней оформлять на бумаге
Около 160кк это лимит для усн, для патента лимит 60кк вроде(он меньше чем у УСН)
Про доп 1% с дохода да оно есть, на патенте используется потенциальный доход вроде, он кроме мск редко где превышает 300к, поэтому на патенте его платить нет необходимости.
В большинстве случаев ИП выгодней чем самозанятость, исключения разве что очень маленькие обороты, менее 20к в месяц (суммы с которой удерживаются суммы в ПФР, фомс)
ах да еще забыл сказать, что в некоторых регионах при открытие ип доступны налоговые каникулы 0, в некоторых регионах они доступны и не при первом открытие ип (можно закрывать и снова открывать) это надо смотреть региональные программы поддержки малого бизнеса, помимо налоговых каникул поддержка может быть осуществлена целевым финансированием, план примерно такой:
Встаете на учет что вы безработный
Ездите в несколько организаций по направлениям (3 штуки вроде) получаете отказы.
Говорите я хочу открыть бизнес поддержите меня (в регионах есть поддержка)
Вы готовите бизнес план
Защищаете бизнес план (им выгодно чтобы уменьшить число без работных), вам даже госпошлину за открытие ип возможно не придется платить
На ваш бизнес план выделяют деньги (которые не надо возвращать) их надо тратить целевым способом, например в бизнес плане можно указать что вам нужен ноутбук, 50% стоймости ноутбука будет за ваш счет, 50% с этих денег, с этих же денег можно оплачивать аренду офиса или коворкинга и прочего (главное все это внести в бизнес план), надо лишь отчитываться чеками и прочим за потраченные деньги.
ПРОФИТ!!!
причем такую штуку можно подавать и на следующий год...
тут можно многое придумать, например открыть такси и 50% машины купить за счет гранта такого, минус один надо бегать по этим бюджетным учереждениям, очереди, составления бумажек, но и профит можно получить, с точки зрения айти это копейки.
такие штуки это интересный опыт и возможно написание отдельных статей на хабре, знаю что некоторые таким образом открывали фотоателье, покупали ноутбук macbook за 50% и фотоаппарат за 50%, также открывали такси, чтобы купить логан за пол цены и еще другие сферы сельское хозяйство например, просто это не совсем тематика хабра, я лично такое не проходил, но есть те кто подобное проходили и "работают" таким образом.
Любой перевод будет проходить через ВЭД
абсолютно нет
вы платите налог 6% с дохода
максимально возможный доход не помню точно около 2.4кк (по 200к в месяц примерно)
2.4 * 0,06 = 0,144кк налогов. (или 144к)
если взять ип на патенте, то сумма всяких взносов ~40k на эту сумму можно уменьшить стоймость патента, в МСК он около 60к или 80к (надо доплатить 60 - 40 или 80 - 40), в большинстве других городов он стоит меньше 40к, можно например прописку сделать НЕ МСК (первый раз когда не мск прописка лучше :) )
плюс сюда доп расходы в виде оплаты расчетного счета пусть будет 500 руб в месяц, 12 * 500 = 6к
Итого ваши расходы будут 46к
причем патент будет работать до 60кк
а самозанятый оборот должен иметь до ~2,4кк - мысль в том что хорошие специалисты скорей всего превысят 2,4кк оборота в год
точно самозанятый это выгодней всего ?
144к - 46к = 98к вы недополучили.
Почитал комменты и ваш пост и замечаю что вы комментариями в коде пытаетесь заменить документацию, комментарии != документация
Хорошо если есть хорошая документация, а также в коде к нужным местам комментарии, но что будет плохого если будет документация, рабочий код, но он будет без комментариев?
По мне ничего страшного, значит комментарии не так сильно нужны для документации.
Другой пример пример где javadoc комментарии излишни если они не привносят никакой информации, например:
Какой смысл тут в комментарии ?
Только приведенный пример не значит что комментарии не нужны, это значит что их как и многое надо использовать к месту.
как то я слишком расплывчато написал, попробую кратко по пунктом сумировать
вместо data-testid можно, а возможно даже лучше использовать стандартный id
пользовательские атрибуты (data-*) нужно использовать по назначению там где нет стандартных.
для того чтобы изолировать тесты от структуры документа и не использовать селекторы в тестах можно использовать page object, но это надо далеко не всем
использование пользовательских атрибутов это не значит что вы отказались от css селекторов.
так кто вам гарантирует что при изменение верстки тот кто верстал не посносил data-testid ?
тесты на то и тесты чтобы не заливать то что не проходит тесты, поэтому тот кто поменяет верстку, будет обновлять и page object, тесты ему напомнят что упало и на что обратить внимания, для этого они и пишутся.
например пусть была некая колонка с балансом в профиле пользователя, а после редизайна она перехала куда то в другое место, на другую страницу (мой баланс например и там текущий баланс и операции пополнения и расходов) как вы ее будете находить не меняя тестов ? будете оставлять колонку на баланс в профиле с display: none ? (костылище)
как в этом случае мне поможет подход озвученный вами ?
тоесть при подобном кейсе в моем варианте.
Разработчик обновляет верстку (редизайн и тд) сфокусировавшись на этом.
Запускает тесты чтобы заметить регресс.
Исправляет регресс у упавших тестов.
MR
В вашем случае на первом этапе помимо фокусирования на задаче, разработчик еще будет смотреть data-* атрибуты и где они используются в тестах, получится он на первом шаге будет делать еще и второй и третий этапы.
где тут отказ от xpath/css селекторов ?
ваше предложение сводится к тому что используйте пользовательские атрибуты в xpath/css селекторах в тестах вместо class/id/tag.
Вот я не согласен на "вместо" я считаю что надо использовать там где возможно стандартные селекторы основанные на tag/class/id, а где необходимо можно добавлять и пользовательские атрибуты, но не строить тестирование только вокруг пользовательских атрибутов.
Чем предложенный вами data-testid отличается от обычного id ?
Почему человеку надо вместо id использовать data-testid ?
причем если посмотреть описание id http://htmlbook.ru/css/selector/id
я даже выделил важное в цитате, как раз то как вы собираетесь использовать его.
просмотрел статью по диаганали, по озвученным проблемам уже давно существует решение в виде page object, отсюда в тестах не используется xpath, а используется page object в котором уже скрыта (инкапсулирована) работа с xpath.
Итог: не обязательно добавлять data-testid можно использовать обычные id, class, tag если они есть, вопрос именования это отдельная тема, не будем спорить нужен ли БЭМ или альтернативы.
Добавляя data-testid мы не перестаем использовать xpath, мы вместо использование классов, тэгов, id. Начинаем использовать пользовательские атрибуты.
я знаю разницу между swarm и compose, но спасибо что напомнили.
я говорил что вместо использования docker-compose утилиты, можно сделать
и далее брать текущие docker-compose.yml файлики и запускать примерно так
и все будет работать так как везде docker-compose.yml версии 3 (тут нет специфичных вещей)
при этом разница в том что человек
Не доустанавливал docker-compose утилиту (в некоторых ос ее надо доставлять дополнительно)
Не изучал параметры утилиты docker-compose (вполне достаточно docker swarm, stack и тд того что идет из коробки)
Плюсом получил возможность примитивную возможность объединять в кластер, которой обычно достаточно ОЧЕНЬ многим (некоторые прод держат на docker-compose и если работает и их все устрайвает то почему бы и не ДА ?)
поэтому если человек ищет инструмент для запуска окружения, я бы в 2023 году советовал в начале использовать стандартный (docker swarm вместо docker-compose), а уже потом он сам выберет нужен ему k8s или k3s или что либо другое.
возможности утилиты docker-compose с лихвой перекрываются docker swarm mode и рациональней начинать изучение с нее в 2023 году (как и годами раньше), раньше году в 2015 когда не было swarm mode да docker-compose было полезно и удобно и некоторые по привычки могут его использовать и дальше.
даже не представляю зачем сейчас изучать docker-compose если можно можно брать эти же самые docker-compose.yml (любые где версия 3.х) и запускать их в docker swarm
docker swarm считается заброшенной, а docker-compose это вообще древний рудимент
возможно я набросил слишком холиварно, но docker swarm по всем параметрам обходит docker-compose, единственный минус это не подеррживает версию ниже 3, во второй там были свои "фишки".
я в свое время тоже пришел к деревьям, даже хотел сделать небольшой веб интерфейс для управления, но как всегда руки не дошли.
Моя идея была в том чтобы была мотивация делать дела из нижнего списка, чтобы видеть верхне уровневую цель, например: Основная цель поработить человечество, ее блокирует построение звезды смерти, ее блокирует необходимость создания стабильного ядра звезды смерти (вспоминаем фильм :) ), ее блокирует отсутвующий специалист, ее блокирует конкретная задача: Позвонить Дарт вейдору в понедельник для рекрутинга архитектора.
Вот когда у тебя список дел состоит из задач конкретных при этом всегда видно глобальную цель и при этом видно цепочку того что оно блокирует это лично меня мотивирует ее быстрее сделать, чем если бы просто была задача: Обсудить с Дарт Ведером вакансию архитектора, какого архитектора ? зачем ? что мне это даст ? и соответственно завершая такую мелкую задачку можно сразу показывать что она может разблокировать и фокусироваться на других задачах, также очень удобно одновременно указывать все известные блокеры которые можно делать паралельно.
Применяя такой подход в реальной жизни я гораздо быстрей достигал поставленных целей.
я бы добавил сюда еще то что тестировщика надо как можно раньше подключать к ознакомлению фитчи, от поставноки задачи аналитиком, чтобы он понимал какой именно результат нужен в итоге.
В идеале аналитик = тестировщик, чтобы кто ставил задачи он их и принимал.