Что я могу дать как наставник?

За два месяца работы

1. Помогу написать пет-проекты на рыночном стеке. Spring-boot приложение с БД и веб интерфейсом / REST API
2. Помогу прокачать резюме, сделать его привлекательным
3. Потренирую проходить собесы. Проведем 2-3 собеседования
4. Помогу выполнить тестовое задание (даже если наставничество уже закончится). Здесь только консультация по выполнению и ревью кода

Все это созваниваясь раз в неделю и чатясь в чатике.

Важно! Ученик должен владеть Java Core хотя бы на троечку.

Если человек не знает Java Core - я могу объяснять определенные темы, при условии, что человек проходит онлайн-курсы. Я не смогу дать всю базу по Java за короткий срок)

Как попасть в наставничество?

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

Если тебе интересно - напиши в комментах 'zoom' и мы договоримся об удобном времени.

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

Есть 10 причин знать SOLID:

0️⃣1️⃣ Часто спрашивают на собесах
1️⃣0️⃣ Знание SOLID позволит писать чистый, читаемый, расширяемый, тестируемый код

Итак, принципы:

SRP (Принцип единственной ответственности): каждый класс должен отвечать только за одну задачу.

OCP (Принцип открытости/закрытости): классы должны быть открыты для расширения, но закрыты для изменения.

LSP (Принцип подстановки Лисков): объекты должны быть заменяемыми своими производными типами.

ISP (Принцип разделения интерфейса): интерфейсы должны быть специфичными и содержать только необходимые методы.

DIP (Принцип инверсии зависимостей): модули должны зависеть от абстракций, а не от конкретных реализаций.

Более подробно можно почитать в статье, к которой я когда-то приложил руку:

Подготовтесь, завтра я скину задачу на SOLID, которую будем решать всем чатом 😎

Всем привет!

Задачка на SOLID.

На фото выше класс, в котором намеренно нарушаются некоторые принципы SOLID. Задача - определить какие принципы нарушаются и предложить в комментах как можно сделать иначе.

Если не вызовет никаких затруднений - скину задачку на SOLID посложнее.

Привет, друзья!

Очень рад большому количеству ответов на задачку про SOLID, так держать 😎
Задачка, можно сказать, решена, и более того, были предложены решения выходящие за рамки вопросов про SOLID - очень круто 👍

Сегодня я провел день записывая видео о git. Признаюсь, ввиду отсутствия опыта, оральный труд дается нелегко. Но я запилил вступление, рассказал про создание/клонирование репозитория, добавление SSH ключика. Дело осталось за малым, рассказать про коммиты, работу с ветками и немножечко, может быть, про git flow.

Перед тем как пойду спать, хочу задать вам один вопрос на ночь:

Почему метод main статический ?

Запилил видео о работе с git для новчиков 🎉

В видео я рассказываю, что такое Git и объясняю логику его работы. А еще показываю:
- как создать репозиторий
- как клонировать репозиторий
- как делать коммиты
- как работать с ветками
- как создавать мердж-реквесты

Надеюсь, оно будет полезным для вас 😊

https://youtu.be/nZriVFWoTec

Друзья, у меня появилась одна идея и нужно ваше мнение.

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

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

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

Те из вас, кто выполнит задание, получит от меня обратную связь по качеству вашего кода.

Выше есть материалы по SOLID и работе с git. Будет отличная возможность оттачить теорию на практике.

Но для этого нужно понять, интересно ли вам поучавствовать в этом)

Поэтому если хотите такой движ, напишите в комментах "хочу покодить".

Если наберется человек 5, я выложу задание на разработку.

Итак 4 человека откликнулись на зов кодинга!

Возможно подтянутся еще желающие, а мы начнем.

Для мотивации:
До тех пор, пока хоть кто-то будет выполнять требования с двумя звездочками (⚛️⚛️), я буду модернизировать задачку таким образом, чтобы по итогу из консольного приложение получилcя Spring Boot проект с REST API.

❗Естественно, сначала я буду объяснять как делать то или иное здесь либо на YouTube

Задачка

Написать хранилище строк с CRUD логикой.

Программа должна уметь сохранять, редактировать, обновлять и удалять переданные в нее строки.

Каждой сохраняемой строке должен присваиваться некоторый id (числовой).

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

Пример API для сохранения:
Ввод: CREATE {some_string}
Вывод: String saved with id = {id}

Пример API для чтения всех строк:
Ввод: GET
Вывод: Выводятся массив всех сохраненных строк

Пример API для чтения конкретной строки:
Ввод: GET 4
Вывод: Выводится строка, чей id = 4

Пример API для редактировани конкретной строки:
Ввод: UPDATE 4 {new_string_value}
Вывод: String with id = 4 updated

Пример API для удаления строки
Ввод: DELETE 3
Вывод: String with id = 3 deleted

Для завершения работы программы необходимо ввести команду QUIT

Строки должны сохраняться в HashMap

Требования со звездочками:

⚛️ Программа должна быть maven проектом
⚛️ Предусмотреть негативные сценарии работы (например пытаемся обновить строку с несуществующим id)
⚛️⚛️ Программа не должна нарушать SOLID принципы. Попробуйте разбить логику программы на отдельные функциональные блоки и каждый реализовать в отдельном классе
⚛️⚛️⚛️ При завершении работы программа должна сохранять содержимое HashMap в какой-нибудь файл. При старте хранилище должно инициироваться из этого файла. Путь к файлу должен быть прописан в конфигах приложения. Должно работать на любом компе
⚛️⚛️⚛️ Программа должна быть покрыта юнит тестами.

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

Да прибудет с нами сила)

В Java есть Checked и Unchecked исключения.

У Checked Exceptions есть свои 👍 и ❌:

👍 Преимущества:
1️⃣ Принудительная обработка исключений: Разработчик обрабатывает или объявляет исключения в коде, предотвращая игнорирование ошибок и обеспечивая надежное ПО.
2️⃣ Улучшение читаемости кода: Объявление Checked Exceptions в методе дает информацию о возможных исключениях, упрощая понимание вызовов метода.

❌ Недостатки:
1️⃣ Избыточность кода: Обработка Checked Exceptions может привести к повторяющемуся коду, усложняющему чтение и поддержку программы.
2️⃣ Ограничение гибкости: Checked Exceptions требуют обработки в каждом вызывающем коде, ограничивая гибкость и повторное использование кода.

И один из вопросов с собеседований звучит так:
А нужны ли Checked Exceptions в принципе? И если да, то зачем?

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

А что думаете вы? Поделитесь в комментах

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

Но сначала скажу спасибо всем, кто проголосовал в опросе выше. Теперь у нас есть слоган 😁

Ранее я выложил задачку, и получил уже целых 4 ссылки на решение. Это очень круто, я прям горжусь собой за то, что заставил вас кодить, и вами за то что вы взяли и сделали. Вы очень крутые🦾

Ближайшие планы теперь такие.
Запишу видосы на которых сделаю ревью кода и выложу тут. В видео получится наиболее полно дать фидбек. Я ленивый и в тексте не осилю 😅

Затем я выложу дополнение к требованиям по задачке, она станет сложнее, но интереснее, вы однозначно прокачаете скилл ООП и узнаете что-то новое.

Ближайшие планы такие, всем желаю хорошо отдохнуть перед новой неделей и кайфануть от нее)

Итак, друзья, я сделал всем ревью.
Все молодцы! Понял, что пока читал ваш код на камеру мало хвалил вас. Но знайте, что вы учитесь, и делать неправильно - часть процесса обучения.
В самом ревью я делал акцент на какие-то общие вещи, сильно в детали не смотрел.
Рекомендации могу дать такие:

1. Разбивайте логику на обособленные функциональные блоки. В контексте данной задачи сделать это можно примерно так:
Пользователь ввел строку - вызвался парсер. Парсер распарсил команду - она уже валидная. Далее эта команда передалась в некоторый сервис, задача которого вызывать тот или иной метод хранилища.

2. Закрывайте ресурсы. Почитайте про интерфейс Closable, Autoclosble, про try-with-resources и блок finaly

3. Практически у всех папка .idea попала в git. Это не комильфо. Смотрите на свой репозиторий на github. Видите в нем папку .idea или папку target - гуглите про gitignore, про то как в него добавить папку.

Остальное увидите в видосах, которые щас появятся.
Продолжайте в том-же духе.

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

@vlad0O_O0 - Это твоё)

@Logoti456 - принимай)

@GenesizAnt - Это ваше)

@VavilovNikita59 - держи)

@MikhailSumarokov ты успел на ревью)