Доброго времени суток, Илья.

Очень ёмкие вопросы в комментарии, по поводу каждого статью наверное можно забабахать. Отвечу кратко на, с моей точки зрения, самый важный. Можно ли устроиться джуниором после курсов.

Вопрос непростой.

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

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

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

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

Но если ограничиться теоретическими занятиями и отработкой техники на пустом грифе, то результат не появится никогда.
Тренер может рассказать как делать правильно. Может посмотреть, что делаете вы и дать оценку. Но для того, чтобы были результаты, нужно регулярно заниматься в тренажёрном зале. Самому. Тут тренер ничего не сделает, этим вам придётся заниматься самостоятельно.

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

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

К собеседованиям тоже придётся готовиться. Если вы понимаете, как устроен динамический массив, но не можете об этом рассказать, то с точки зрения работодателя это всё равно как если вы вообще не знаете, что это такое. Придётся тренироваться отвечать перед зеркалом.
Поэтому ещё раз скажу, устроиться джуниором реально, но очень многое зависит от вас.

P. S. В роли наставника я увы, сейчас выступать не могу, курс постоянно корректируется на основе обратной связи, на это много времени уходит. Если хочется пообщаться именно со мной, пишите в личку, я обязательно отвечу.

Кому станет хуже от того, что юзер станет чаще выигрывать?

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

Больше похоже на таракан, чем на профессиональную этику.

Таракан, да, но по мнению некоторых, такие тараканы отличают хороших программистов от идеальных ))

Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.

Да, я очень удивился. Не мог отказать себе в удовольствии ответить )))

цель подобных курсов всегда одна — заработать денег.

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

не знания продать. не научить за оплату. а именно — заработать денег.

Отдельно хочу сказать за себя. Я тут именно для того, чтобы научить программировать тех, кто этого хочет. Вопрос денег лично у меня вторичен. Мне неоднократно говорили, что это нездоровая позиция, возможно я её перерасту когда-нибудь, но пока что вот так.

за два три месяца плотных занятий, по 6...8 часов каждый день — можно выйти на уверенного джуна. и что там растягивать на 11 месяцев ??

Совершенно согласен, можно. Хотя я бы, конечно, слово максимум убрал бы )). Если есть желание и силы впахивать по 6...8 часов каждый день в течении трёх месяцев, то можно. Особенно, если готовишься к конкретной позиции в конкретной компании. Я даже знаю случаи.

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

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

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

Сложно поспорить, всё именно так и есть. Именно поэтому я всегда повторяю, что ничего невозможного нет, нужно только желание и труд. Только желание по-настоящему нужно и трудиться действительно придётся. Это очень важно осознавать.

Ну, утверждать-то можно что угодно

Врядли нас обманывают ))). Я делюсь своим опытом, комментаторы своим. Мне кажется имеет смысл верить, что по крайней мере субъективно у них и правда всё получается понятно и код нормально читается другими людьми

Практикующие такое утверждают, что понятно всем. Я, правда, не поддерживаю эту позицию. Лично я считаю, что надо рефакторить код по мере возникновения вопросов по нему. Как не избегай состояния потока, всё равно ты при разработке периодически в него попадаешь.

Прошу прощения за недостаточную детализацию. Если серьёзно писать на эту тему — комментария не хватит. И вот эту важную деталь, как и многие другие, я не упомянул. Использование коллекций с JPA вообще нетривиальная штука. Мало того, что в некторых случаях надо делать remove а потом add одного и того же объекта, так ещё и надо делать много странных движений для маппинга, если хочешь убрать дополнительные запросы. Плюс надо помнить, что в Hibernate зачастую используется на ArrayList или что-то в этому духе, а какая-нибудь другая структура. Когда я пытаюсь вкратце рассказать, постоянно что-то упускаю.

Это просто особенность реализации HashSet и TreeSet.

Контракт на интерфейс Set гарантирует, что если сделать сначала remove, а потом add, то в коллекции окажется новый объект. Наверное надо было сразу написать про все операции целиком.

В таком случае вы завязываетесь на недокументированное поведение.

Мне кажется нет такого. Какое поведение из того на что я ссылаюсь не документировано?

Именно для того, чтобы объект не менял бакет, hashCode должен возвращать константу

По хорошему движок JPA не должен поместить в контекст две разных энтити, указывающих на одну и ту же строку. Вся штука в том, что нужно держать в одной коллекции несколько энтити, которые есть в контексте, которых ещё в нём нет и не забыть про энтити, которые пока не попали даже в БД.

Чтобы когда кладёшь в Set энтити и там уже есть энтити с таким id, новая энтити вытеснила старую.

Ну и иногда удобно делать arrayList.contains

Если переопределить equals, то проблем с определением быть не должно, даже если одна из сущностей ещё не находится в контексте.

Не совсем. Там получается два разных потока. В одном контекста много. Потом через какое-то время (через пару тройку дней) разработчик входит в другой поток, где он уже забыл контекст и стремится сделать всё как можно более понятным.

Честно говоря не ясен их смысл у мутабельных объектов.

Конкретно в энтити — есть необходимость безопасно добавлять и в Set.

Добавили в сет, потом поменяли?

Да, добавили в сет пока id == null, потом записали в БД и id сгенерировались и при этом сет должен работать корректно.

Вариантов-то всего три: сравнивать по ссылке, сравнивать по id, сравнивать по всем атрибутам. Почему плох третий — автор написал, теперь сравним первые два варианта.

Правильно сравнивать по Id, но добавить условие, что если id ==null, то equals выдаст false. Ну и плюс вернуть константу в hashCode конечно

Проще не создавать никакого поля и использовать equals и hashCode по умолчанию.

Такая позиция существует, но тогда получается, что будут проблемы с пониманием, что две энтити у которых равен id относятся к одной и той же строке в БД

И все равно так не делайте. Это выстрелит через непонятное время.

Вот если написать в hashCode не константу, то да, выстрелит. Не сразу, но обязательно будут плавающие баги.

Ваши хешмапы превратились в тримапы. logn это не очень много, но все равно легко можно написать код который думая что там o(1) внезапно начнет тормозить на пустом месте.

Для этого не надо использовать энтити как ключи в хешмапе. А когда используешь коллекции типа HashSet, надо помнить, что нельзя класть туда много элементов. Но вообще надо просто помнить, что надо делать связи OneToMany в которых много элементов