Ну многие ставят на то что M1 просто сменит x86 архитектуру в мире потребления, а виртуальные машины нивелируют проблему в мире энтерпрайза. Если в мире потребления M1 действительно начнет заменять, это будет даже хорошо, для потребления вполне себе железка. Как я понял у M1 сейчас одна проблема, с графикой они не могут пока как 86 работать. Для потребителя.

не знаю, хакинтош пробовал, извращение еще то выходило, половина железа отваливается. проблемы почти со всеми радиомодулями и другой переферией.

Что бы Нормально работать с Ios нужна экосреда IoS. В том числе и мак, пусть не прошка, но что бы был мак. Можно конечно попытать счастья и заменить эмуляторами. Даже что то делать, даже стейбл какой никакой выкатывать. Но это опять таки будут поделки уровня "на грани аппрува".

"у меня такая же нога, и не болит" ) сейчас даже на AMD работает.

Есть настоящая эмуляция от Corellium. Хоть они и судятся с Apple, возможность есть и без маков с ios работать

они кстати выиграли суд.

Да, но не окончательно

Привет. Такой вопрос,  на проекте используется подтверждение по ссылке которая приходит на почту, с помощью каких библиотек/инструментов можно автоматизировать  этот кейс в:
1) Rest-Assured (API)
2) Selenium webdriver (UI)
Язык использую java

для работы с почтой я бы предпочел библиотеку javax mail

Например, использовать локальный сервер mailhog, отправлять  на него письма и через его api проверять ссылку

https://github.com/mailhog/MailHog

а там дальше зависит от вас, какой тип автоматизации тестового сценария использовать. RestAssured если апи и selenium в случае с ui

Спасибо

Пс, посоны и девчонки.
Уверен, что у вас куча опыта по моему запросу.

Есть проект, в котором есть back + web + iOS + Antroid.

Какой релизный цикл лучше всего подойдёт для таких систем?
Известно, что ревью приложений ios/anrdoid занимает время в офф.маркетах, поэтому "секундного деплоя" тут не получится, как для back+web.

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

Кто как сживался и получалось ли менять процесс релизов на что-то более интересное?

Культ релизов зло. Ну конечно если не боитесь что-то пропустить, то можете попробовать. Сразу советую прикручивать службы мониторинга и жалоб :)  А если дела денежные или медицинские, можете влететь на куда больше чем стоит из-за того что "флоу выглядит убогим".

Работал в таком проекте —  back + web + iOS + Antroid . Релизы были через месяц-два. Руководству захотелось релизов чаще (а ещё посокращать народ). Нововведения, решения сверху, шумиха, неразбериха, люди стали увольняться, я тоже уволился, В итоге — компании бег за быстрыми релизами ничем не помог.  Нет в них благодати.

Я работал в бек-веб и у нас был ci/cd - каждая фича катилась по мере готовности, было прекрасно и великолепно.

Мониторинги были, конечно же.

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

Так же был и в проекте со всеми 4 платформами.
Бек релизился по готовности (с обратной поддержкой), а мобилки по мере готовности.
Тоже великолепно.

некоторые выкручиваются тем, что часть функционала делают изменяемой на серверной части. Тогда можно релизить чаще.

Быстрые релизы очень крутая штука.
Потому что они становятся полностью автоматизированными и не нуждаются в «особом контроле».
Тут проще почитать умных людей на этот счёт, чтобы не спорить на пустом месте.

Без каких-либо внешних ограничений на скорость - лучший путь это релизить фичи по готовности, чтобы потом конфликты не собирать из-за «отлёживается кода в ветках»

Да у нас это уже размазано везде: фичетоглы внутри и снаружи (flickr).

ну, не в релизах счастье. Есть простое правило: работает - не меняй, не работает - меняй!