Swartex

Выбирайте PHP. Месяца не хватит даже на изучение материала.

Расскажите плиз о технологии, и чем развёрнутей, тем лучше.

Вот захотел ты сделать сайт SPA или PWA с любимой тебе вёрсткой на базе Twitter Bootstrap и любимой библиотеки Vue. Сверстал. Поповеры не появляются, дропдауны не выпадают, модалки не открыватся, формы не валидируются, клики не работают.

Оригинальный Twitter Bootstrap имеет поддержку интерактивных элементов на Javascript. Реализовано это на библиотеке jQuery. Если делаешь на Vue, придётся подключать ещё и jQuery, что лишняя библиотека на 100+ килобайт, что, конечно, не катастрофа (пока ты не на мобилке).

Vue работает с состояниями привязывает данные к отображению, а jQuery работает с DOM и событиями. Это вопрос производительности. Работа JQuery начитается когда загружен и распарсен JS и HTML. Работа Vue начинается в тот момент, когда загружен и распарсен JS, то есть чуть раньше. jQuery модифицирует DOM на лету, перестраивая текущий документ. Vue работает с shadow DOM, а затем подсовывает уже готовую интерактивную страницу в пустой документ, что быстрее (разница в секунды на десктопе, десятки секунд на м...).

Vue реализует компонентную парадигму. Куски страницы являются изолированными кусочками кода (HTML CSS JS), которые цепляются между собой динамически, а обмениваются данными через аттрибуты и события. Предположим, что вы решили следовать компонентной парадигме, тогда согласно вот такому примеру нужно будет увязать самостоятельно все интерактивные компоненты. Компонента-кнопка. Компонента-поле ввода. Компонента-форма. Компонента-контейнер. Получается около 50 компонент. Для некоторых надо будет написать логику на jQuery. Если посмотреть на код jQuery этих микрокомпонент, то он окажется несложный, его вполне можно переписать на Vue. Ну там класс заменить или клик отработать. Когда от кода jQuery не останется следа, его можно будет из проекта удалить.

И вот получается Bootstrap-Vue

На компоненты побили. От Jquery избавились. Написано в единой парадигме. Работает быстрее.

Добавляем тот факт, что в Vue можно не импортировать компоненты, которые не нужны (например, я не работаю с дропдаунами и модальным окнами) и код становится меньше, грузится быстрее, работает быстрее.

Так же будет Не лишним оценить технологию: плюсы, минусы, стоит ли вообще с этим работать ...

Это сам изучай и сравнивай. Навыки и опыт воздушно-капельным и через Internet не передаётся

Вам злые дяди не разрешают другие переменные слать, кроме message?

Собрать новый массив:

const newArr = arr.map(function({ ...n }) {
  return this.reduce((acc, k) => (acc[k] = acc[k].toLowerCase(), acc), n);
}, [ 'firstName', 'lastName' ]);

Обновить существующий:

const keys = [ 'firstName', 'lastName' ];
arr.forEach(n => keys.forEach(k => n[k] = n[k].toLowerCase()));

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

1) Можешь почитать статьи от Рамблера, Варгейминга - у них вся инфраструктура идет на питоне. Там достаточно интересно рассказывается, почему был выбран питон, и какие сложности им приходится преодолевать.

2) Если коротко, то за скорость разработки ты платишь гемором при поддержке и расширении. Плюс есть некий дефицит кадров.

Так почему кто-то берет python, а не Java:

- 9 из 10 проектов будут адекватно работать на python (так как они не разростутся до уровня мега-компаний)
- многие любят python, на нем приятно писать проекты.

Самый типичный кейс интерпрайза на Питон:

1. Сделали какой-то стартапчик на питоне.
   
2. Стартап выстрельнул
   
3. Начали расширяться и расти.
   
4. Так как все было написано на питоне, остались на питоне.
   
5. Ключевые моменты стали переписывать/дополнять go/node.js сервисами
   

Учи WORDPESS. Заказов на фрилансе куча, да и учится легко.

@input="onInput($event, product)"

methods: {
  onInput(e, product) {
    product.quantity = Math.max(0, parseInt(e.target.value) || 0);
  },
},

или

watch: {
  products: {
    deep: true,
    handler() {
      this.products.forEach(n => n.quantity = Math.max(0, parseInt(n.quantity) || 0));
    },
  },
},