German Jet

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-шным программерам для непосредственной имплементации в сетевом оборудовании.

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

IT Ops, на мой взгляд, поинтереснее (сам такой потому что), так как задачи разнообразнее. Но в DevOps, например, денег больше платят. Хотя в IT Ops сейчас тоже много из DevOps наприлетало -- Infrastructure as a Code, ansible/chef/puppet, хранение конфигов/плейбуков в VCS, вот это вот всё. И это действительно приводит к тому, что нужно меньше людей, чтобы управлять существенно бОльшими по размеру инфраструктурами. Но и квалификация этих людей тоже должна быть выше, и программерский бэкграунд какой-то тоже нужен. Потому что даже в IT Ops очень много автоматизации, которую нужно писать руками на Shell, Powershell, Python, смотря где как принято.

Отдельный денежный сегмент -- это DBA. Oracle, PostgreSQL, MariaDB -- прокачанных DBA мало, и стоят они дорого. С другой стороны, рынок, где требуются DBA -- довольно узок. И чтобы не было проблем с поиском работы -- квалификация должна быть высокой.

Есть ещё NetOps, т. е. сетевые инженеры. Но там сейчас грустно -- несмотря на то, что для работ в операторских сетях, например, нужна нефиговая такая квалификация и знание особенностей кучи вендорского железа (редко кто строит гомогенные в смысла вендора сетевого железа сети, в основном сборная солянка - -Cisco/Juniper/Mikrotik/Dlink/Huawei), но зарплаты там (по Москве) -- 90-100 тысяч. При этом практикуются ночные/выходные дежурства и всё такое. Можно найти прекрасные места, где сетевой инженер будет зарабатывать бОльшую сумму, но в целом -- как-то так.

Если резюмировать -- в IT Ops ниже порог вхождения в целом. Т. е. можно найти работу, где не требуется серьёзная квалификация, но и денег будет соответственно.

DevOps -- порог вхождения выше, т. к. DevOps подразумевает выполнение вполне конкретного набора задач, и для их выполнения уже вряд ли возьмут человека с улицы, надеясь, что он "по ходу разберётся" (а вот в IT Ops или даже NetOps в мелких и средних конторах ещё может прокатывать). Квалификация требуется выше, но и денег больше.

DBA -- всё ещё сложнее, чем с DevOps. Рынок узкий, квалификация нужна высокая, но зарплаты тоже высоки, повыше DevOps, по моим наблюдениям.

В чистый NetOps сейчас уходить... Ну такоэ... Есть крупные конторы, где этим можно нормально зарабатывать, но всё равно, квалификация требуется высокая, а денег относительно требуемого объёма знаний платят не так уж много. Вот IT Ops + NetOps -- это да, тут можно найти хорошую работу. Но для этого книжек придётся прочитать в полтора раза больше, чем отдельно IT Ops и в два раза больше -- чем отдельно NetOps :-)

Напишите файловый сервер с возможностью загрузки файлов через ftp-клиент, через web-морду, через SOAP ( или REST), через мобильную приложуху с аутентификацией, базой юзеров, также можно в базе хранить какую-нибудь метоинформацию о файле. Например, может быть такой маленький личный фотоальбом с подписями(блог-постами, комментами etc.), фотки из которого доступно скачать и залить повсякому. Попробуете всё.
web и Java = Enterprise. Это приложения масштаба предприятия, т.е. они как-то автоматизируют его бизнес-процессы и документооборот, переносят его работу в web и электронный формат. Они также могут общаться с другими приложениями, системами. Отсюда пляшем. Вам нужно какое-то предприятие, у которого вся работа в оффлайн, всё плохо, бюрократия и ад. Придумайте сложный бизнес-процесс со сложными сущностями. Разный и изменяющийся во времени и пространстве уровень доступа. Интеграция с другими приложениями или гос.сервисами. Электронный банк, электронные платежи, электронная валюта. Наворотить можно много чего.
Начните с малого - какой-нибудь справочник-реестр с функциями CRUD - создать, прочитать, редактировать, удалить запись. Далее прикрутите систему прав и ролей пользователей(не все могут создавать, редактировать и тем более удалять). Добавьте работу с файлами - скачать, загрузить, экспорт в pdf и exel. Продолжайте накручивать своё приложение функционалом - личка и чат, доска объявлений, имитация отношений начальник - подчиненный (тайм-менеджмент, таск-менеджмент, сбор отчетов каких-нибудь по работе), уведомления (в почту, в системе, м.б. попробовать с смс), напишите другую маленькую систему и заобщайте их между собой по SOAP или REST(например, другая система может читать из справочника и что-нибудь туда писать). Берите какое-нибудь гипотетическое предприятие (склад, магазин, автосервис, школа, больница, завод и т.д.) и представьте, что ему надо свой документооборот перевести в электронный вид и максимально автоматизировать бизнес-процессы.
Из фреймворков - семейство Spring.

По личному опыту скажу, что C# и Visual Studio - это самый эстетически приятный тандем из всех, с которыми приходилось работать. C# прост, понятен и элегантен настолько, насколько это возможно.

Касательно перспектив:

Если в Ваших планах карьера программиста, то я бы однозначно посоветовал C# и .NET. Так как .NET-программистов значительно меньше, чем php-разработчиков, как следствие зарплаты значительно выше(но и вакансий меньше). Так же безусловным плюсом является то, что в случае с C# Вы не ограничены лишь веб-приложениями: на C#, помимо веб приложений, пишутся десктопные приложения, мобильные кроссплатформенные приложения(Xamarin), игры, о которых Вы упомянули, а это значит, что если, к примеру, какое-то направление Вам пришлось не по душе, Вы за гораздо меньшее время сможете переквалифицироваться. В случае же с php Вы имеете дело только с веб-приложениями.

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

Итог: я бы посоветовал C#. Погружайтесь в платформу .NET и становитесь экспертом. Удачи)

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

2 - конкретно в WinForms можно отрабатывать вообще разные формы последовательно

using System;
using System.Windows.Forms;

namespace X
{
    internal static partial class Y
    {
        /// <summary>
        /// Главная точка входа для приложения.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(A = new fmA());
            // bla-bla-bla with login
            Application.Run(B = new fmB());
        }
        internal static fmA A;
        internal static fmB B;
    }
}

3 - для WPF не подскажу, но наверняка оба подхода можно рассмотреть и пробовать искать аналогии

ps для WinForms

Как закрыть главную форму из дочерней?

буквальный ответ - ни как, закрытие главной формы, это завершение Application.Run(A = new fmXXX()); и если вы не модифицирутете код Main- тогда это завершение программы

Делайте то что нравится, но не отступайтесь перед трудностями. Я от многих слышал что у меня хороший мозг и все такое, что мне учиться проще чем другим и что я ленивая задница. И только я знаю что что бы там ни было у меня в способностях я каждую неделю сижу и изучаю новый материал, ставлю эксперименты и ищу "подходящий" мне путь. Прошел далеко не одну специальность в IT: делал сайтики, как вы говорите, работал на себя, был фронтом, бэком, лидом, руководителем, экспертом, сейчас вот архитектор и это далеко не конец.

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

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