German Jet

Каждый инструмент хорош для своей задачи.

Сейчас рынок таков:
1. Битрикс не нужен в продуктах и сервисах.
Если вы продуктовая компания (inhome разработка) и делаете проект на вырост для себя который поддерживать и развивать будете долго, а также у вас в компании есть опытный разработчик который знает толк в паттернах - берите Symphony/Laravel. Это окупится гибкостью.
Хотя если у вас интернет магазин - можно подумать о гибриде, на начальной стадии это окупится.

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

3. Выход на крупных клиентов
Если вы крупная компания, то битрикс даст выход на крупные многомиллионные тендеры, которые очень многие идут по документации как требование. Создание высоконагруженных сайтов для крупнейших компаний РФ - это гораздо интереснее чем клепать мелкие сервисы на laravel/symphony.

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

С точки зрения разработчика понимание современного PHP и использование composer отвязывает вас от конкретной платформы, и позволяет использовать лучшее из любой фреймверков в любой платформе.
Не нравится роутер в битриксе? Берите из laravel. Хотите более функциональных контроллеров чем те которые появились в 18 ядре? Возьмите из symphony/laravel. Не нравится ORM? Возьмите Doctrine.
Все из вышеперечисленного не сложно прикручивается к битриксу, и позволяет вам использовать все сильные стороны системы и фреймверков. В битриксе сильная сторона в данном контексте: хорошая админка которая позволит затащить крупный проект в короткие сроки (требования рынка). Для ИМ - много готовых интеграций со всеми сервисами которые ставятся быстро и просто.

Для PHP разработчика если работать планируете только в продуктовых компаниях можно обойтись только знанием фреймверков. Если хотите более уверенно и широко смотреть на рынок: то битрикс+FW.

Очень согласен с коллегой, обозначившего что хорошо готовить проекты на битрикс умеют очень немногие, т.к. бест-практикс нигде не обозначен. Возьмите за основу вот эту заготовку, и хорошо ее изучите, она даст вам понимание что такое более менее современный проект на битриксе
https://github.com/regiomedia/bitrix-project .

Базовая цена за домен .com - $7,85 в год. Это та сумма, которую чарджит Verisign, администратор зоны .com.
Все что ниже этой стоимости, можно считать, спонсируется регистратором. Зачем регистраторам это делать? - либо привлекать новых клиентов (и тогда надо смотреть на цены продления доменов), либо субсидировать за счет сопутствующих услуг (тут уже сложно что-то рекомендовать без понимания, что еще вы готовы заказывать)

serializer = UserLevelSerializer(queryset_, many=True)

Так же в queryset вам стоит сделать select_related, чтобы избежать кучи лишних запросов к БД

Для миддла надо подтянуть только п. 3. У Светы Смирновой есть несколько отличных презентаций по работе с explain, они легко находятся гуглом.

Еще желательно различать транзакции и блокировки, когда что использовать.

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

Вообще, по моему опыту, не стоит переоценивать результаты интервью. Когда я 5 лет назад ходил по собеседованиям, то после двух из них, которые я сам посчитал проваленными, мне прислали предложения о работе.

Добрый день.
Я бы обратил своё внимание на "сценарии".
Один сценарий для создания новой записи, второй для редактирования существующей.
Соответствующие правила валидации для каждого сценария.
https://www.yiiframework.com/doc/guide/2.0/ru/stru...

p.s.

Если просто создать форму с 2 полями field_3, field_4, то злоумышленник зная какие еще есть поля, может отправить и поля field_1, field_2 и они перезапишутся.

А как же RBAC?

P.S.S
Не имеет смысла и может привести к ошибкам валидации.

if (******** && $form->validate()) {
    ******
    if ($model->save(true)) {
        *****
    }
}

Тем более, что валидация в методе save() включена по умолчанию.

public boolean save ( $runValidation = true, $attributeNames = null )

Как уже писали выше, вывести алгоритм формирования Таблицы Менделеева будет весьма проблемно. Расположение зависит от свойств самих элементов (количество незаполненных электронов на внешнем слое, валентности и заряда ядра). Выбирать все эти данные для формирования таблицы, просто не эффективно.
Гораздо логичнее сделать таблицу в которой будут №строки,№столбца и название файла с описанием. По сути та же самая таблица Менделеева в электронном варианте, позволит выбирать элементы по строкам, столбцам или точному расположению.

Есть очень неплохой , подробный туториал от Mozilla на русском. Руководство по Django Там кроме прочего рассмотрены не совсем очевидные вещи при использовании CBV.
Могу порекомендовать книгу "Two scoops of django" в ней собраны best practice от опытных разработчиков.

Ну, если тебя устраивает, что твоё имя вряд ли будет красоваться рядом с новым прорывным алгоритмом, невероятно изящным подходом, самым лучшим языком программирования или обобщённой методологией, если тебе нравится процесс ради самого процесса, если устало бросаешь, но потом всё равно возвращаешься — попробуй. Главное, не иди в эту область ради денег. Если будет желание, интерес, всё остальное приложится. Найди для себя достаточно интересную область и приятный современный язык (то есть кресты, паскаль — мимо). Если уже на достаточно уровне знаешь английский, если в математику тыкаешься, то может и Кормена со Скиеной осилишь (это по алгоритмам). Ну и SICP стоит прочитать (потом сам сможешь язык или даже компиллятор/транслятор свой написать). С таким багажом ты заткнёшь за пояс охапку джунов, если не миддлов.
Единственное, не стоит лезть в Web. Слишком низкий уровень входа, слишком большая конкуренция со студентами и пакистанцами. Если башка варит и живёшь в крупнейшей тройке городов (или есть наглость попробоваться к иностранцам), то и джуном возьмут. И в реальных боевых условиях опыт накопится очень быстро, даже если кажется, что уже старик (кстати, в 25-30-35 надо сдавать свой общий уровень тестостерона и, когда он начнёт плохо вырабатываться, потихоньку переходить на ЗГТ, подкалывая его себе до уровня 22-23 лет; а это и интеллект, и энергия, и силы, и выносливость, и здоровье, и долголетие).
Вообще, в программисты на заре профессии шли умудрённые опытом хардкорные инженеры обоих полов, кому за тридцать (если не сорок), это потом понабежали малолетние хипстеры с андеркатами на гироскутерах и вытеснили взвешенный, вдумчивый подход. С другой стороны, пока рыночек в рассее стремительно схлапывается, мировое число вакансий в области программирования постоянно растёт. Так что при наличии желания и интереса, найти своё место определённо можно будет.
Удачи.

Изучайте методы, которые давно отработаны для показа данных в различных картографических фреймворках для web.
Подходов несколько. Например, разбивать запрашиваемые данные на фрагменты одинакового (в проекции окна приложения) размера. Это позволяет не запрашивать те, которые у вас уже загружены. Можно запрашивать область больше вашего viewport-а (и комбинировать это с предыдущим методом). И делать новые запросы только тогда, когда величина scroll-а от точки предыдущего запроса превышает какое-то значение. Например, пользователь открыл карту, приложение запросило данные на покрытие viewport-а плюс 50% его ширины с каждой стороны. Пока пользователь не сдвинет карту дальше 25% ширины viewport-а от начальной точки, новых запросов не делать. Также можно озаботиться тем, чтобы сервер не пересчитывал всё каждый раз, а именно - сделать prerender для разных масштабных слоев. И использовать кэширование на стороне сервера. Или вообще превратить ваши маркеры в статичный (или закэшированный, условно статичный) растровый слой, а с сервером общаться только когда пользователь в маркер ткнёт, чтобы о нем информацию получить.

В отличии от остальных тут отметившихся у вас есть отличный математический бэкграунд и навык преподавания. Легко устроитесь на 100+, только работу подольше поискать надо, ее меньше чем в веб и мобилках, программировать будете в матлабе)) А все отметившиеся так и будут дальше формошлепить на фрилансах, не подозревая, что карьера на этом закончилась.

P.S. Вот недавно знакомый устроился на работу в западную коммерческую контору, занимается моделированием сигналов LTE и 5G для последующего внедрения в 3gpp. Прогает в ML, а на основе его кода даётся ТЗ C-шным программерам для непосредственной имплементации в сетевом оборудовании.