Сергей

Я могу ответить сразу за все сферы: все думают, что платят за то, что работаешь в IT, в итоге - всё IT начали "наводнять" неучи-PR-щики.
А работодателям - это выгодно: они эмулируют конкуренцию и снижают ЗП всем подряд, включая нормальных знающих работников, ссылаясь на то, что мы ещё найдём тучу подобных тебе на твоё место и постепенно отсеивают незнающих, оставляя ЗП хороших знающих сотрудников на начальном уровне.
В итоге: трудозатраты, образование и опыт претендентов стали абсолютно размазанными на IT-рынке труда, что способствует отсеву "чужих" людей из IT.
Реальные сотрудники - превратились в скитальцев, которые не хотят сталкиваться с подобными вещами и которые ищут грамотных работодателей (готовых хорошо платить за работу и их опыт) и высококлассный коллектив, который был сформирован этим же работодателем для успешного ведения своего бизнеса.
В любой структуре, в момент её расширения, появляются различные вакансии для новых сотрудников с разным опытом и знаниями.
Но, в большей степени, ключевую роль играет необразованность и невладение предметной областью самих руководителей таких новых подразделений и невозможность грамотно оценить потенциал кандидата до приёма на работу для конкретных задач, поставленных этому подразделению.
И как следствие - виноват всегда тот, кто не справился с задачей, а не тот, кто допустил это.

21749 до скольки знаков должно округляться? Можно получить 21750, 21800, 22000, 30000, 100000, 1000000, ... Как программа должна определить где остановиться?

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

Не буду касаться целесообразности вашего решения. Об этом уже много написали.
Что касается этики, мое мнение следующее:
Ваше поведение НЕ является неэтичным, поскольку:
1) Вы не нарушили своих обязательств перед студией в рамках заказа, который выполняли для нее.
2) Уход от них к вам клиента произошел не по вашей инициативе, а по инициативе клиента и из-за ошибки студии в договоренности с клиентами.
3) На вопрос студии вы ответили честно и не стали их обманывать.

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

Дополню интересной книгой, которую вы обязаны прочесть, если поймете её то сами ответите на вопрос правильно. Читается за пару вечером и очень интересна

А что вы хотели? Не разработчики же деньги дают, а клиенты! Хочешь денег значит надо думать о клиенте и хорошо понимать поговорку "Любой каприз за ваши деньги". НО. При этом надо четко доносить до руководителя о сроках реализации с ВНЯТНЫМ пояснением почему! При этом убедиться, что он об этих рисках ооочень хорошо осведомлен и понимает их также как и команда разработчиков

Мастер на все руки - это круто и полезно для расширения кругозора.
Хорошо для некого обзора-старта в ИТ.
Но не более.

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

Увольняйтесь.

Идите в большую контору.
Сразу договоритесь - что вы там не будете фулстеком.

Если вам интересны разные направления - то поспециализируйтесь на одном, потом на другом.

Крайне важно наличие доброжелательных высокопрофессиональных коллег в зоне быстрого доступа.

Фулстеки редко нужны (ето или должность еникея, или должность СТО)
Если компания прикипела к тебе, то начинай делать свой отдел

Если жмотятся - проводи ревизию своих знаний через прохождение собеседований на разные позиции.
Попробуй себя в собеседовании на мидла (потом джуна) по бекенду и фронту - так ты поймешь на каком ты уровне

Автор, это чревато для тебя тем, что твоя зарплата это тот оклад, который указан в договоре.

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

Остальное - премия, которую тебе вообще платить не обязаны.

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

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

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

ничего особенного не произошло (этично/не этично это фигня), просто вы работаете без договора и это не было прописано.

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

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

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

Как это ни странно, самым правильным с токи зрения поисковиков было бы как раз то показывать страницу, то отдавать ошибку 404 если её нет. Итого она то появлялась бы в поиске то пропадала из него.

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

Третий вариант заключается в том что бы посмотреть, подумать сколько посетителей приносят такие страницы по всему сайту, бывает так что переходят исключительно на внутренние и такие страницы разделов проще закрыть от индексации в robots.txt и тогда проблема отпадёт сама собой.

Задача_о_ранце

Знаете, я с вами соглашусь, что хорошую вводную по Elastic трудно найти. Пока сам не переварил доков и не набил шишек многие элементарные понятия оставались для меня неясными. Поэтому вот моя вводная: Elastic можно использовать как NoSQL БД, только надо быть внимательным, т.к. всё-таки его основная задача поиск, а не удовлетворение функций БД. Например, если вы не настроили хранение исходных данных, а только индексацию, то свои данные вы уже не извлечёте из него. НИКОГДА. Только отдельные выражения, удовлетворяющие условиям поиска. Всё, тупик. Так же нельзя повторно индексировать уже загнанные в него данные. Т.е. перед загрузкой данных надо грамотно настроить индексацию, т.к. перестроить индекс, как это делается в реляционной БД невозможно. Нужно придумать новую схему индексации и перезалить данные в Elastic. Именно поэтому основное использование Elastic - как дополнение к существующей БД из которой данные можно перезалить по одному или полностью в Elastic (можно, конечно сделать схему Elastic->Elastic, но тоже есть нюансы).
Ещё пару слов про схему. Это ЛОЖЬ, что в Elastic нет схемы данных. Она как раз есть и ооочень жёсткая. Жёсткая до того, что однажды определив, вы не сможете её поменять. Изначально Elastic оказывает медвежью услугу, разрешая вам дополнять схему по-умолчанию, но когда вы разберётесь с этой темой, то можете обнаружить, что Elastic "понастроил" такого у себя внутри, что остаётся только охреневать и переделывать всё явно, отказавшись от его "услуг" по автоматическому добавлению полей в схему.
Так же в Elastic очень непросто строить сложные запросы на поиск и агрегатные запросы. Совершенно неинтуитивно. Но если освоитесь, то будет вам счастье. )))
Несмотря за такие "страшные" вещи - Elastic классная система и по производительности агрегатных запросов не уступает платной версии MSSQL в поиске в многопроцессорных системах (проверял на одинаковых аппаратных конфигурациях с 16 ядрами). Так что если вам хочется большую скорость в агрегатных запросах и главное - это бесплатность, то берите и осваивайте Elastic. Мощности и возможности у него огромные. Но... нужно потратить приличные усилия на изучение.

Это не система уравнений. Равенство транзитивно. b = ax = c => b = c. Конец.

Так принимайте напрямую через WebMoney, Яндекс.Деньги(яндекс+прием с карт) и др.систем, которых нужно.