Ровно неделя до старта менторства DMdev!

Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)

Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka

PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень

Самый младший студент на первой ступени менторства😁

Юбилейный 15ый старт двух ступеней состоялся 🎉

Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.

Спасибо каждому за доверие, let’s go 🚀

P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)

Отвечаю на #ВашВопрос
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?

Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.

На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.

Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:

// Это использование дефолтного маппера
public Optional<UserReadDto> findById(Long id) {
        return userRepository.findById(id)
                .map(userReadMapper::map);
}

// Это использование динамического маппера, переданного с контроллера
public Optional<T> findById(Long id, Mapper<User, T> mapper) {
        return userRepository.findById(id)
                .map(mapper::map);
}

А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.

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

Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.

Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.

Но есть и хорошая новость: достигнув какого-то уровня, например, Lead, очень легко и с гораздо меньшими затраченными усилиями потребуется, чтобы вновь оказаться там после долгого перерыва.

#23 Мой путь

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

В то время на слуху у всех в Минске был сравнительно молодой район под названием “Новая Боровая”. Я сел за руль своего Polo и поехал на разведку. К моему удивлению, еще сидя в машине и подъезжая к “Новой Боровой”, я уже обратил внимание, что этот район сильно отличается от всех других: повсюду велосипедные дорожки, дома необычно окрашены, огромный рисунок Леонардо Да Винчи на всю стену, весь район разбит на закрытые небольшие кварталы по 5-6 домов в каждом, внутри которых был двор с беседками, барбекю, площадками для детей и спорта.

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

Когда подошел мой черед, и я начал беседовать с консультантом - пришло довольно досадное понимание. Во-первых, те квартиры, что мне понравились, еще в процессе строительства, которое займет около года. А значит нужно будет ждать их сдачи и продолжать платить за арендное жилье по 350$. Во-вторых, нужны будут деньги на ремонт, т.к. это будет новая пустая квартира без ничего вообще. В-третьих, мне придется отдать все деньги, что я скопил на тот момент. И в-четвертых, следующие 9 месяцев придется платить за ипотеку по 4000$ каждый месяц. На тот момент - это была моя зарплата в компании Synesis. Другими словами говоря, жить я буду только за счет курсов, что я преподавал в it-academy.

Это было довольно рискованным делом, но мое желание было слишком велико. Я сам по себе человек, который обычно быстро принимает решения. Помню, как моя будущая жена, с которой я еще не был знаком на тот момент, всегда удивлялась, как я, например, могу зайти в первый понравившийся магазин за шапкой и купить ее за 5 минут. А я просто не люблю все затягивать и долго размышлять над потенциально другими вариантами, которые могут мне понравится или могут быть лучше. Поэтому в этот раз тоже было не исключение - я согласился прямо в тот же день: выбрал квартал, дом, двухкомнатную квартиру в 59 квадратов на 2 этаже, и косметический ремонт. За все вышло чуть больше 83.000$.

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

#my_little_story

#ВашВопрос
👇
Денис, привет, спасибо большое за все что ты делаешь, развиваюсь благодаря твоим курсам очень сильно. Хотел спросить, как думаешь, через какое время нужно менять проект. Я уже два года на одном проекте, он развивается, все хорошо. Но может нужно какую то насмотренность тоже набирать или это ерунда?

Здесь нет однозначного ответа, когда стоит менять проект или компанию. Но как показывает статистика - это в среднем около 3 лет.

Я бы лучше акцентировал внимание на цели, которые ты приследуешь:

🎯 Если цель - это получить больше зарплату, то да, ты быстрее можешь повысить ее при смене компании (до какого-то порога на рынке или порога твоих профессиональных навыков).

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

🎯Если хочешь развивать свои навыки и не стоять на месте, то тут лучше прислушиваться к себе и чувству комфорта.

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

О себе хочу сказать, что я пробовал разные варианты и разные "балансы". И пришел к выводу, что ощущения счастья и удовлетворение жизнью у меня уходили по двум причинам:

1️⃣ когда я начинал чувствовать себя очень комфортно. Наверное, природа наделила парней таким качеством, чтобы мы хотели развиваться, преодолевать себя и чего-то добиваться.

2️⃣ когда я чувствовал огромную нагрузку, или когнитивная сложность проекта/моих обязанностей была значительно выше моего приемлимого максимума.

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

PS. В моем случае, я нахожусь на одном проекте уже 2.5 года.

☝️Полный комплект из 13 курсов, которые будут участвовать в праздничной распродаже 18 марта

P.S. Среди участников будет разыграно одно место на менторство DMdev 1 ступени и две часовых консультации со мной

#ВашВопрос
👇
Как относишься к гексагональной архитектуре организации кода? Слой сервисов работает исключительно с классами-доменами, что усложняет работу с БД, из-за закрытия сессии на уровне портов.

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

Сама идея вокруг гексагональной архитектуры очевидна и понятна: мы хотим разъединить/отвязать части целого приложения, чтобы иметь возможность разрабатывать и менять эти части независимо друг от друга. И эти идеи не новы, они есть и в других архитектурах, например, той же классической n-tier архитектуре, о которой я рассказываю на протяжении многих моих курсов.

Например, на своем проекте я по достоинству оценил лишь отделение интерфейса взаимодействия с приложением, где я пишу код абстрагируясь от протоколов - будь то это HTTP, gRPC, Stubby, и т.д. Все это на себя берут "адаптеры".

Когда же дело доходит до "downstream" зависимостей, которые будут использоваться в бизнес логике (например, базы данных, message brokers), то почти всегда приходится спускаться до нюансов работы инструмента, чтобы работало именно так, как надо, а не так, как получится.

Что касается вопроса - я не вижу большого смысла в усложнении работы с базами данных, потому что:

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

- идея про возможность заменить СУБД на лету только звучит круто, на практике никто этого делать не будет за редким исключением (что только подтвреждает правило).
Данные - это самое важное в приложении, на основании чего потом и рассчитывается перфоманс приложения, и аналитика будет строиться, и LLM обучаться, и т.д.

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

У нас в команде есть очень хорошая практика - оставлять коментарии к своим же пул реквестам.

Обычно это относится к тем вещам, в которых ты не уверен, есть сомнения/несколько альтернативных вариантов, и хочешь уточнить у других.

Это также очень сильно улучшает концентрацию вниманию тех, кто будет ревьювать твой пул реквест.

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

Что думаете по поводу этого?)
Может кто-то также использует?