German Jet

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

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится

В 1С заранее предопределенные объекты.
Прикладные программисты не могут создавать произвольные объекты, могут только в предусмотренных создателями объектах вариациях менять их свойства (набор полей) в предусмотренных создателями объектов пределах. "Создатели объектов" = "системные программисты". Vs "прикладные программисты".

Поддерживается создание произвольных объектов - как внешние компоненты - но это за пределами языка 1С. Используется редко. Встроенных хватает для 99% случаев.

1) Большинство (если не все) лицензионных соглашений запрещают не только установку, но и использование контрафактного программного обеспечения. Т.е. использовать ПО, узнав о его пиратском происхождении, уже нельзя. Таким образом ссылаться на то, что ПО было установлено другим специалистом, практически бесполезно.
2) Маленькие компании считают, что они никому из проверяющих не нужны, большие - что у них "всё схвачено и все подмазаны". Чушь. Знаю о небольшом предприятии (порядка 200 сотрудников) пищевой промышленности в маленьком городе (50-70 тысяч населения), которое тряхнули за пиратский софт. Почему их, не знаю; рядом десятки таких же предприятий с тем же уровнем лицензионного порядка. На крупном предприятии в случае проблем как раз виновный будет один сисадмин, так как у руководства "всё на мази", а сисадмин - паршивая овца на абсолютно законном предприятии.
3) Любое письменное обращение к руководству с требованием/прошением/предупреждением о нелегальном программном обеспечении подтвердит информированность специалиста о наличии пиратского ПО и его понимание незаконности действий.

IMHO, если увольняться не вариант, то как минимум не устанавливать ничего лично; информацию донести до руководства, но в недокументированной форме, чтобы потом ещё больше не встрять.
Маловероятно, но гипотетически, если в должностной инструкции указано, что специалист устанавливает программное обеспечение, предоставляемое работодателем, работодатель становится заинтересованным лицом.

В принципе все правильно. Берете и делаете. Серебрянной пули нет.

Особенно порадовало, что "все занимаются тестированием"- это правильно. Лишь бы это не было "все - значит никто". И следите за тем, чтобы тестирование давало результат - либо тикет в системе либо фикс. Если баги находят, но просто говорят о них на кухне - это не тестирование. Если баг фиксится сразу, это не значит что коммит-сообщение можно ляпнуть "fixed some strange bug" - он должен содержать описание сценария в котором он происходит и как он влияет на пользователя.

Улучшайте коммит-сообщения. Так чтобы из них можно было собрать патчноут и красиво показать пользователю. А не куча невнятного "внутряка". Формулируйте с позиции пользы, это заставит разработчиков немного больше гордиться проделанной работой, а следовательно добавит им мотивации. Для примера посмотрите как пишут патчноуты передовые представители игровой индустрии.

По автоматизации .. подводные камни такие:
- если автотестов много - их долго выполнять. Начните с небольшого количества 20-50. На них вы обкатаете внедрение и процесс. Не считайте никакие ROI - это бред. Чем считать ROI лучше написать еще один полезный тест.
- архитектуру тестов старайтесь организовать так, чтобы работу по их написанию можно было распараллелить. Например если у Вас Page Object - один может писать компоненты из которых другой может строить сценарии.
- ваш сервис сильно зависит от доступности источников данных - проверяйте доступность источников регулярно, особенно если эти данные вы получаете не по API, а выковыриваете парсером.
- сделать тестовую базу данных - правильно. Автоматизируйте ее свертывание-развертывание через контейнеры.
- по приоритетам автоматизации - точно так же - по "абстрактной" значимости. Хороший источник для идей - багтрекер. Кластеризуйте ошибки по типам и делайте выводы.
- не делайте автоматизацию ради автоматизации - в первую очередь чините продукт, потом тесты.
- не усложняйте тесты ради того чтобы они справлялись с более сложными условиями, упрощайте условия.
- автотесты будут сыпаться по непонятным причинам. Делайте как можно более полезное логгирование. Если тесты выполняются в произвольном порядке - это тоже может быть одной из причин. Любой рандом в тестировании - зло. Учитывайте это при наполнении тестовой базы данных. Желательно, чтобы тестовая база всегда содержала одинаковые данные. Смотря что у Вас за база. Если это только пользователи это одно, а если у вас там хранятся аггрегированные данные, то нужно время от времени пересобирать тестовую базу из свежих источников и проверять работу тестировочных скриптов с ней.
- автоматизацию тестирования можно применять не только для тестирования конечного продукта, можно тестировать миграции схемы базы данных, восстановление базы из бекапа и прочее.

Можете почитать мои ответы по этому хабу, может найдете там еще ответы на какие-то близкие Вам вопросы.
Вот некоторые из моих советов-ответов более-менее общей направленности:

Как добиться независимости в тестах (phpunit)?
Правильное тестирование Javascript?
Как систематически подойти к тестированию в малой компании разработчиков?
С чего начать изучение на должность QA автоматизатора?
Как создать отдел тестирования?
Какие шаги тестирования сайта?

Читайте:
"Lessons Learned in Software Testing" (Kaner, Bach, Pettichord)
"Experiences of Test Automation: Case Studies of Software Test Automation" (Graham, Fewster)
и вот эту вики: TestAutomationPatterns (Кстати, ее инициатор и редактор та же Dorothy Graham. Есть даже пару записей ее лекций на ютубе - советую глянуть)
В ней прям шаблоны. Проблема - решение. Бесценная вещь. Мне в свое время очень помогло, чтобы понять "что не так" и как это лечить.

Если форма заполнена не полностью, то кнопка отправить должна быть неактивна.
Если форма заполнена невалидными данными и/или неполностью - кнопка "Отправить" должна быть неактивна и неверно заполненые поля должны показывать подсказку.
Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются. Переполнение поля тоже.
Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (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гб