Saboteur

поисковикам пофиг.
А регистратор имеет значение.

Человек или понимает или нет.

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

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

Разве вопрос в языках? IMHO вопрос в платформе.
Какой браузер будет это выполнять?
Сейчас вот разные табы работают в разных процессах, то есть с разделяемой памятью и т.п. И на это ушло много лет..

Посмотрите https://developers.google.com/web/updates/2018/10/...

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

В то время как крон вы можете поставить в то время, когда не выполняются бэкапы, когда на сервере минимальная активность, и выполнение может быть контролируемым, с логированием, с расширенным функционалом.

Сама идея обновлять данные при активности какого-либо пользователя - вполне нормальная, просто не для вашего случая. Она для случая, когда нужно обновлять небольшой блок данных.

P.S. А разобраться с крон в любом случае необходимо - это стандартный и популярный инструмент. Разобравшись с крон вы будете лучше понимать когда его использовать, а когда нет, а не отталкиваться от того, тут же разбираться надо.

1. Договор - полюбому. Чтобы можно было прижучить.
В нормальных команиях также секьюрити проводят регулярные таунхолы, особенно для новичков, где рассказывают о безопасности. И приводят пару примеров, как кто-то расшарил кусочек кода, как его засудили на много денег и добавили в черные списки всех компаний.
Это для тех, кто по глупости может.

2. Делите исходники на части. Автоматизируйте деплой так, чтобы разработчик это руками не делал и никуда не лазил - сделал коммит - CI сервер автоматом закачал все нужное из разных репозиториев и задеплоил. Надо нескольким разработчикам - сделайте несколько тестовых окружений, чтобы разработчик мог зайти в Jenkins или Teamcity, нажал одну кнопку и выбрал куда ему деплоить. Но своих логинов парлей у него не было.

3. В любом случае, если кто-то захочет стырить код - он это сделает. Сделать так, чтобы не было доступа для тех, кому этот доступ нужен - это только навредит проекту.
Поэтому пусть у вас работает нормальный HR.
Пусть тимлиды присматриваются к людям, не доводят до конфликтов.
Не дают доступ ко всему до прохождения испытательного срока.

И это все равно не гарантия. Смиритесь =)

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

Вы должны уметь ваше приложение развернуть на локальной машине, и понимать как его развернуть на другой машине.
Jenkins\Teamcity - это тулзы, где девопс старается автоматизировать то, что вы разворачиваете на локальной машине. Вы его консультируете где и откуда вы читаете конфиги, возможно у девопсов есть какие-то централизированные способы для этого. Но Jenkins\Teamcity вам нужны на уровне продвинутого юзера. Можно на месте попросить девопса вам показать базу.

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

Задача девопса - это скейл и автоматизация. Девопса потому и стали выделять в отдельную должность, что появилось много приложений, которые нужно развернуть не на дев машине и напродакшене, а на нескольких тест окружениях, на нескольких регрешн, на нескольких продакшн (отказоустойчивость и так далее), и накопилось работы на приличное количество человекочасов. Но это не значит, что девопс вообще должен разбираться в вашем приложении и тем более бизнес-логике лучше, чем разработчик.

То есть по канону, даже если в одном файле надо букву поменять - следует запускать полный цикл выгрузки?

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

В этом случае вы просто не мучаетесь выбором, а просто кодите.
Ну а одна буква это может быть и - на +. Без тестирования в продакшен?

Agile технологии хорошо работают в опытной команде. Поэтому со временем и тимлиды и вы должны лучше справляться с оценкой.
* Со стороны лидов - качественнее прогнозы, качественнее оценка работы подчиненных
* С вашей стороны - корректировка самого agile процесса - размер спринтов, количество и время на митинги, размер буфера.

Одно дело, если такая задача выпадает 1 на 10, другое дело если таких ошибок половина. В первом случае просто поправить размер буфера который у вас в спринте выделяется на "непредвиденные обстоятельсва", который должен покрывать больничные, внезапные дэйоффы, недооцененную сложность тасков. К концу спринта, если буфер еще есть, можно брать из бэклога какие-нибудь мелочи

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

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

Изучиьт php на базовом уровне не проблема. Возьмите и изучите.

Изучить php на уровень уверенного junior-а, умеющего хотя бы в базовую работу одного из популярных фреймворков - долго, много.
Но для уверенного JS-джуниора будет гораздо проще, потому что есть определенное количество технологий, которые пересекаются - работа с json/xml/css/html/sql, базовая настройка веб-сервера, сертификаты, установка компонентов.

PHP на текущий момент умирает уже десятки лет, и все равно он доступен на каждом хостинге. IMHO поднимать nodejs на бэкенде для сайта-визитки это ненужный оверинженеринг. Поэтому базово подтянуть PHP - маст хев.

Углубляться в изучение фреймворков - уже отдельный вопрос. Смотря как устроитесь.

Какие самые топовые двигатели существуют?
Где заканчиваются возможности двигателей и начинаются возможности других способов что-либо двигать?

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

Так же и тут - "топовых" небывает, есть популярные для решения конкретных видов задач.
Любая CMS это обычно веб-продукт, и при желании ВСЕ можно реализовать в CMS, просто иногда задача бывает такова, что нет смысла переписывать CMS, а проще написать с нуля свое.