Pull to refresh
1
0

User

Send message

В Китае сначала был бурный рост населения, который попытались сдержать ограничением рождаемости. После этого, родители предпочитали родить мальчика, как более перспективного ребенка. Из-за этого произошел недостаток невест и они стали очень избирательны к партнерам, отдавая приоритет обеспеченным со своим жильем. Рост произошел за счет ранних поколений, а проблемы с созданием семьи возникли уже у поздних поколений.

Это у них цена за день, такая завлекалочка.

Большое спасибо. Именно взгляда с такой стороны и в таком формате мне не хватало чтобы понять времена в английском 15 лет назад.

Да, предложение было в том, чтобы код держать изолированно в контейнере. Дополню, что в моем сообщении смысл был не в том, что тянуть гит-репозиторий на сервер это плохо, а в том, что прокидывать код с диска в контейнер на проде это плохо. Плохо или хорошо использовать гит как инструмент доставки того же docker-compose до серверов — я в этом не спец. У нас все деплой-конфигурации вынесены от кода в отдельный репозиторий, но при деплое они все равно тянутся из гита на сервер (на мастер-ноду кластера) и по ним разворачиваются приложения на слейвах.
Если для локалки
 volumes: - ../:/app
допустимо, то для прод-окружения тянуть код на машину и прокидывать его в контейнер выглядит чуждо самой концепции докера, плюс добавляет сложность при обновлении, когда недостаточно docker service update, но нужно еще и пулить код с гита. Еще одним недостатком такого является чрезвычайная сложность или даже невозможность быстрого отката (blue green deployment). У себя в проекте для fpm и nginx я наследуюсь от соответствующих образов и клонирую при билде код проекта внутрь образа. Из минусов такого подхода — теряется кеш при каждом релизе, но, по-моему, плюсов от такого подхода больше.

P.S. У вас не было проблем с производительностью php при использовании докера? Я, конечно, ожидал оверхеда 5-10%, но по факту у меня докер медленнее натива минимум на 30-50% на одинаковых машинах.
3/7 вопросов на знание множественного наследования, когда по-хорошему нужно знать, что множественное наследование это bad practice.
Полтора года назад начинал с Junior Python и Django. С питоном ситуация не печальная, трудоустроиться реально, но вакансий (особенно джун) меньше, чем по PHP, Java, JS. PHP очень похож на питон, где-то упрощен, что-то хуже и сложнее чем в питоне, а PHP и Python фреймворки похожи и основаны на одинаковых идеях, взять для сравнения те же Django и Symfony, например. Можете быстро подучить PHP, стартовать карьеру с него, а через 1-2 года уже рассматривать вакансии на столь любимом питоне.
В 1С-программировании противоположные проблемы — технологий и фреймворков там раз два и обчелся, что-то новое выходит хорошо если раз в год, никакой гонки технологий нет. В этой же статье автор поднял проблему того, что мировой дизайнерский рынок осваивает новые технологии и работают по новым стандартам, за которыми мало того, что неплохо бы поспевать, так и на текущем месте работы автора эти новинки никому не нужны.
Я сам год назад сбежал из 1С через веб-Python. Альтернативным путем был Java и в частности android, но, после того как попробовал, отказался от этого варианта из-за большого порога вхождения. Сейчас несколько жалею, потому что junior-java\junior-android вакансий больше, чем junior python, за них платят больше и, как ни странно, по ним меньше требования по технологиям и знаниям. Аналогичная ситуация в middle и senior. 80-90к у junior конечно фантастика, я бы ориентировался на 50-60.

Information

Rating
Does not participate
Registered
Activity