German Jet

Если форма заполнена не полностью, то кнопка отправить должна быть неактивна.
Если форма заполнена невалидными данными и/или неполностью - кнопка "Отправить" должна быть неактивна и неверно заполненые поля должны показывать подсказку.
Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются. Переполнение поля тоже.
Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (radio buttons) можно проверить выставляется ли значение по умолчанию если должно или не выставляется если не должно. Бывает что выставляется хотя не должно.

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

Не думайте о количестве тесткейсов, думайте о том, в чем вы хотите убедиться.

Что-то какие-то замудреные ответы вокруг да около. Ничего конкретного...
Многие уже написали: "Entity" это сущность. Но никто так и не объяснил для чего... попробую вставить свои 5 копеек. Ну и мой ответ не будет привязан к Yii. как уже сказали там используется другой подход.

Как уже сказали Entity представляет сущность, например пользователь.
Итак, Entity у нас это пользователь. Мы знаем что у пользователя в любом случае есть идентификатор, имя, фамилия. Думаю, для примера хватит.
Так вот.
Когда вы достали данные из базы в некой модели пользователей, что вы сможете сделать? Ну допустим положить их в массив и в нужный момент вывести как вам угодно, но... по мере роста проекта, пользователь должен будет выводиться в разных частях веб приложения. В одном месте достаточно имени, в другом месте достаточно фамилии, а где-то нужно фамилия и имя. Допустим в БД вы будете хранить имя и фамилию в отдельных столбцах.

И смотрите что получается. Если у вас есть комментарии и там нужно вывести "имя фамилия", так же есть страница подписчики. Там тоже нужно вывести "имя фамилия". И там и там выводится один пользователь, но внешний вид вывода будет разным. И если пойти по способу "данные в массиве". То для каждого вывода вам нужно будет делать что-то подобное:
echo $user['name'].' '.$user['last_name'];

А таких выводов может быть десятки.
Но если вы вместо массива будете использовать объект (класс) user
То внутри вам достаточно создать метод:

public function getFullName(){
   return $this->name.' '.$this->last_name
}

Теперь во всем приложении и в любом файле вы будете знать, что у вас есть метод, который выведет имя и фамилию. Поэтому этот объект вы можете передавать куда угодно. Например в любое из десятков представлений (views) которые будут уверены в существовании одного метода.

И когда вы решите поменять местами и писать "фамилия имя" во всем приложении. Вам достаточно будет поменять это в методе getFullName()

PostgreSQL + PostGis. Хранить в виде обычных координат желаемой точности. Возможно выборка любой сложности.
Сейчас у меня база координат занимает более 70гб, выборка координат внутри желаемого полигона занимает примерно 6мс на обычном hdd.
При желании можно треки запихать в виде multiline из которого потом легко вытащить отдельные точки

P.S. связку PostgreSQL + PostGis использует OSM, где база планеты в распакованном виде легко переваливает за 500гб

Без фреймворка SPA написать можно, только Flask там не при чем. 1) гуглите как писать REST API на фласк, 2) читаете фленегана про яваскрипт, 3) доганяетесь learn.javascript.ru про современные API браузеров и SPA собственного приготовления у вас в руках.

Берясь за написания импорта я обычно стараюсь думать не о том как побыстрее обновить побольше товаров, а о том, как побольше товаров не обновлять.
Первая и самая простая оптимизация добавить к свойствам товаров еще одно - HASH и писать туда md5 от сереилазованного массива которым вы хотите обновить товар. Дальше, при следующем обновлении вы перед Update будете вычислять от сериалазованного массива которым хотите обновить товар, этот Hash и обновлять товар только если он не совпадает с сохраненным хэшем и записывать этот новый хэш.
Такая схема очень удобна в случае если источник не умеет отдавать только изменившиеся товары или товар состоит из нескольких элементов ИБ (Товар+Торговое предложени+Элемент свойств). Кроме того помним что цена тоже хранится отдельной сущностью и для нее можно провернуть тот же трюк. Вычислить md5 прямо сильно быстрее чем сделать запись.

Кроме того следите за тем чтобы вашем кастомном импорте не было ничего кроме записи в update внутри цикла. А то всякое видеть приходилось.

Вообще записать 1000 товаров за минуту в базу, без картинок - это полная ерунда. Должно хватить любой производительности, если конечно не выяснится что у вас не 100 ТП к каждому товару.

И да - убедитесь, что и товары и ТП и все ИБ в которые вы пишите во время импорта хранят свойства в отдельных таблицах, а не в общей.

В настройках модуля веб-форм отключите упрощенный режим, заходите в редактирование вопроса, во вкладке Ответ будет таблица, в столбце Параметры пишите дополнительные параметры, например, placeholder="Значение"

Все, разобралась, надо приводить к единому типу данные, тк из json идет строка, а у меня в id идет int
SELECT pr.*, cat.name as cat_name, cat.alias as cat_alias, vn.name as vn_name FROM `jsonproduct` AS pr
LEFT JOIN `categories` AS `cat` ON cat.id = CAST(JSON_EXTRACT(`product_json`, '$.category_id') AS SIGNED)
LEFT JOIN `vendor` AS `vn` ON CAST(product_json->'$.vendor' AS SIGNED) = vn.id
WHERE product_alias = 'my-alias'

Я вам посоветую опубликовать ваш плагин под gnu-like лицензией без всякой защиты и продавать консалтинг и внеочередные хотелки юзеров

Любой тип защиты потребует вашего времени и с не нулевой вероятностью приведет к багам
А наивная защита для популярного плагина - еще и бесполезна
Надежная защита в виде бинарника с защитой от реверса - не тривиальная штука. И ее не написать без опыта в области реверса

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

Полноценный 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 к нему ( если они конечно отличаются)

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

Что касается грамматики, то лично я за классические бумажные учебники (хотя бы и в электроннм виде). Более того, я даже больше ратую за грамматические справочники. В них информация хорошо структурирована, я думаю, это должно понравиться программистам. Правда, ни один, даже толстый справочник не даст вам полного представления о всех нюансах грамматики. Если хотите иметь более детальные знания, придется обложиться многими учебниками и мануалами. Но здесь кроется одна опасность. Часто в разных книгах изложены одни и те же сведения, но по-разному. Это может запутывать, если не поймешь, что на самом деле в них говорится одно и то же разными словами. Иногда данные из одного источника могут прямо противоречить данным из другого. В общем, есть опасность погрязнуть во всей этой грамматике, вечно пребывая в процессе и не достигая результата.

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

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

Прежде всего, не всегда нужен фронт с js-фреймворком. Часто вполне достаточно обычных страничек. Но если действительно нужен развитый фронт, то бэк перестаёт использоваться для рендеринга шаблонов и выступает как REST- или GraphQL-сервис. Из Django для этого даже специализированное и очень удобное решение выросло - Django REST Framework.