Тоже интересен этот момент, так как по опыту использования data driven ui, самое сложное место это стык бекенда и вьюшек на приложении. Чтобы написать вьюшки нужно знать нуьюнасы приложения и как этот json парсится приложением, с другой стороны чтобы бекенд отдвал этот json его нужно как то разместить на бекенде, где в зависимости от логики приложения будет генерится этот json
Наверняка были случаи когда в команде есть люди с которыми не хочется работать, как вы решали такие проблемы? добавлю, что эти люди могут быть полезны компании и просто взять и уволить\перевести с одной команды в другую не вариант.
Спасибо за статью, есть пара вопросов:
За сколько времени и человекоресурсов были переписаны приложения?
Нет ли проблемы порога вхождения нового человека в эту систему? Тут же просто сверстать блок в приложении уже не получится? Верстка для приложений приходит с сервера?
Интересный пост, но кроме как «потоком сознания» назвать не могу. Если по теме — то ответ на вопрос какие минусы у фалкона и почему он больше не нужен: сам по себе фалкон по функциональности и возможностям не выделяется среди конкурентов, но при этом имеет минус в виде того самого расширения для php, которое некогда дало ему славу благодоря, котороый о нем у знали. Почему минус? Да потому, что это дополнительные затраты на установку этого расширения и отладку если что-то пошло не так, в принципе минус не существенный, но даже в таком виде уже смотрится как пятое колесо.
Проблем с зависимостями не было так как прошло уже достаточно времени с выхода php 7.1 и уже все успели поправить либы под новую версию.
Контейнер используется для изолированного запуска автотестов, тут в принципе нет ничего сверхестсественного — заранее подготавливается образ с необходимой конфигурацией и затем запускается через CI
Если какой-то метод в апи нужно сделать несовместимым, то можно оставть старый метод и создать новый. Новые клиенты будут пользоваться новым, старые старым.
Сервисы между собой общаются по http, никкакой специальной инфрастуктуры, пока, для этого не поднято. Пишем максимально автономные сервисы, чтобы было как можно меньше связей между ними.
Тоже интересен этот момент, так как по опыту использования data driven ui, самое сложное место это стык бекенда и вьюшек на приложении. Чтобы написать вьюшки нужно знать нуьюнасы приложения и как этот json парсится приложением, с другой стороны чтобы бекенд отдвал этот json его нужно как то разместить на бекенде, где в зависимости от логики приложения будет генерится этот json
Спасибо за статью.
Наверняка были случаи когда в команде есть люди с которыми не хочется работать, как вы решали такие проблемы? добавлю, что эти люди могут быть полезны компании и просто взять и уволить\перевести с одной команды в другую не вариант.
За сколько времени и человекоресурсов были переписаны приложения?
Нет ли проблемы порога вхождения нового человека в эту систему? Тут же просто сверстать блок в приложении уже не получится? Верстка для приложений приходит с сервера?
Хочу уточнить на счет какие по вашему есть метрики для измерения работы тимлида?
Или кто вообще как измеряет работу тимлида?
Контейнер используется для изолированного запуска автотестов, тут в принципе нет ничего сверхестсественного — заранее подготавливается образ с необходимой конфигурацией и затем запускается через CI