Полтора года назад я запускал курс.

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

https://caffe.senioravanti.ru/

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

Привет, брал у тебя курс 1,5 года назад, и только пару дней назад довёл проект до ума.

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

(захостил - ссылка в начале поста)

Делал как курсовой проект для предмета "разработка информационной системы" в ВУЗе. Все зубы об него обломал.

По другому предмету будет ещё и мобильное приложение для этой системы.

Стек пришлось несколько раз поменять.
Итоговый стек:
Бэк: Spring Java, Kotlin, GraphQL, jOOQ, PostgreSQL, MongoDB -> 3 микросервиса (сервис продуктов, авторизации и взаимодействия с s3).
Фронт: Vue.js TypeScript .

Конец.

Имхо вышло огонь! 👍

PS Надеюсь у меня в итоге тоже получится «довести до ума», свою менторскую деятельность, и я снова начну «причинять пользу» другим 🥲

Теперь у меня есть copilot)

А тем временем идет четвертая неделя работы без выходных.

Надо заканчивать настолько любить программирование. Кажется до добра это не доведет 😅

Но по крайней мере последние выходные мне оплатят в двойном размере, что в целом приятненько.

Кажется виден свет в конце тоннеля, но тоннель что-то не заканчивается 🤪

Надо бы конечно сделать пост про Java….

Ненавижу Java 🥹

Directed by Robert B. Weide

Кстати, а ты знал, что мем с титрами Directed by Robert B. Weide взят из сериала «Умерь свой энтузиазм»?

Узнал только что, пока гуглил как эта херня пишется. Совпадение? Не думаю

А как у тебя дела? Расскажи че-нибудь, пажалуста 🥹

Вы помните разговоры с уточкой?

Все это, херня, как говорил мой школьный друг.

Вместо того, что-бы говорить с уточкой, гораздо лучше с кавказским акцентом проговаривать свои действия 😎

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

А бонусом вы прокачаете свой нейролингвистический кортекс (чтобы это ни значило)

Я начал с балкарского, потому что это однозначно +20 к внимательности.

Друзья!

Вот вот закончится год уходящий, и начнется год приходящий.

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

Хочу пожелать каждому того, что желаю себе.

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

С новым годом, друзья. Счастья вам сейчас и всегда ♥️

А ты доводишь свой GPT до нервного тика? 😂

PS Готовлю одну вкусняшку для вас 🤌 Скоро чем-то порадую

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

Давно не было активности в канале — давайте это исправлять.

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

▶️ я выкладывал задание
▶️ делал ревью решений
▶️ показывал своё решение
▶️ усложнял задачу дальше.

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

Новую задачку постарался подобрать так, чтобы она не требовала:

🔧 алгоритмов
📐 паттернов проектирования
🍃 Spring и фреймворков
📦 очередного CRUD

Все эти вещи полезны и важны, но они вынуждают повторять шаблонные решения. Здесь хочется другого.

Хочется, чтобы:

🔧 вы сами проектировали структуру
🏗 принимали архитектурные решения
⚠️ сталкивались с возникающими проблемами
💡 предлагали свои идеи и могли их реализовать в коде

При этом полностью уйти фреймворков и товарищей не получится.
Где-то мы, возможно, подключим бд
📄 где-то — Excel,
🤖 где-то — Telegram-бота.
(я сам хз че будет, это все просто примеры)

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

Формат остаётся прежним:

▶️ Я публикую задание
▶️ Вы делаете свои решения и присылаете
▶️ Я делаю ревью первых трёх решений на каждом этапе
▶️ Показываю своё решение (не «правильное», а просто один из возможных вариантов)
▶️ Добавляю новое требование — и мы повторяем цикл

Можно будет:

🟢 начинать с самого начала
🧩 подключаться на любом этапе, взяв за основу мой вариант
🍿 или просто смотреть разборы и сравнивать со своим подходом

Если формат откликнется — накидайте реакций, и стартуем.
Следующим постом выложу первое задание.

Задание 1

Будем разрабатывать консольное приложение — тайм-трекер ⏱ .

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

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

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

📌 Терминология

В описании задачи я буду использовать свою терминологию (вы можете использовать любую):

Проект — логическая сущность, для которой ведётся учёт времени
Трек — интервал времени

📂 Формат участия

💬 В процессе можно задавать любые вопросы в чате

🔗 Чтобы получить ревью, нужно выложить решение в git-репозиторий и прислать ссылку

🏁 Ревью получат первые три человека, выложившие решение

Ready, steady, go: Техническое задание

Как посчитать продолжительность времени?

⚠️ОСТОРОЖНО СПОЙЛЕРЫ! ⚠️
Не читай код, если ты делаешь задание и весь такой САМОСТОЯТЕЛЬНЫЙ

Накидаю вариантов того, как посчитать продолжительность времени между двумя временными метками.

Вариант 1. Старый добрый Date. 📅

Просто берем и делаем так:

Date d1 = new Date();
waitSeconds(1);
Date d2 = new Date();
long duration = d2.getTime() - d1.getTime();

И получаем продолжительность в миллисекундах между d1 и d2.

Вариант 2. Еще топорнее 🪓

Если не хочется сталкиваться с подкопотными календарными преобразованиями метода getTime у класса Date, можно сделать практически тоже самое, но без класса Date:

long time1 = System.currentTimeMillis();
waitSeconds(1);
long time2 = System.currentTimeMillis();
long duration = time2 - time1;

Вариант 3. Для тех кто устал от Java 7. 🎱

Еще один интуитивный вариант - LocalDateTime. Делаем все тоже самое, заменяя ряд ключевых слов:

LocalDateTime ldt1 = LocalDateTime.now();
waitSeconds(1);
LocalDateTime ldt2 = LocalDateTime.now();
Duration duration = Duration.between(ldt1, ldt2);

И получаем класс Duration c богатым как швейцарский нож API 🪚.

Вариант 4. Для тех кого смущает локаль и часовые пояса 🌐

Абсолютно такой же вариант, как и 3, но локально-независимый: Instant вместо LDT:

Instant instant1 = Instant.now();
waitSeconds(1);
Instant instant2 = Instant.now();
Duration duration = Duration.between(instant1, instant2);

Остается всего 1 вопрос, комрад.

Как сложить несколько Duration (➕) ?

Все просто, кэп, юзай метод plus:

Duration d1 = Duration.ofSeconds(1);
Duration d2 = Duration.ofSeconds(1);
Duration d3 = Duration.ofSeconds(1);
Duration total = d1.plus(d2).plus(d3);

Раздел призыва к действию

Сможешь придумать другой правильный/упоротый вариант? Накидай дичи в комментах 😏

Мой любимый блогер выпустил очередной мозгодробителтный видос 🤯

Если еще не знакомы с его творчеством- настоятельно рекомендую 🤌

https://youtu.be/v6HoOOp5fII?si=tQ3tRbUeZkrL9uux

Представь что ты - разработчик языка программирования

null — источник боли.

Код компилируется, выглядит корректно, а потом падает в рантайме с NullPointerException.

В Kotlin есть управляющие конструкции для работы с null.
Два часто обсуждаемых инструмента — это:

▫️оператор !!
▫️функция requireNotNull(...).

Оператор !!

val value: String? = getValue()
val result = value!!

Оператор !! обещает, что значение точно не будет null.
По сути он говорит компилятору:

«Бро, тут точно not null»

Если ожидание оправдывается — всё работает.
Если значение всё же окажется null — приложение падает с NullPointerException.

Альтернатива — requireNotNull(...)

val result = requireNotNull(value) { "value must not be null" }

requireNotNull работает иначе:

▫️явно проверяет значение на null
▫️если значение null, выбрасывает IllegalArgumentException
▫️позволяет задать осмысленное сообщение об ошибке

В отличие от !!, здесь:

▫️проверка не скрыта
▫️ошибка читается как нарушение контракта
▫️сразу понятно, что именно пошло не так

Рассмотрим на примере

Есть метод, который принимает строго not-null параметр:

fun sendEmail(email: String) {
    // ...
}

И есть nullable-значение:

val email: String? = user.email

Вариант с !!

sendEmail(email!!)

Мы передаём nullable-значение, уверяя компилятор, что оно точно not null.
Если это окажется не так — получим NullPointerException без контекста и будем разбираться, где нарушен контракт.

Вариант с requireNotNull

sendEmail(
    requireNotNull(email) { "User email must not be null" }
)

Здесь ошибка:

▫️возникает в момент передачи параметра
▫️содержит осмысленное сообщение
▫️сразу указывает на причину проблемы

Ключевая мысль

Оба варианта компилируются.
Разница проявляется только в момент ошибки — и именно там она критична.

⁉️ И главный вопрос

Если requireNotNull закрывает боль с null более правильно,
если !! считается «грязным» и потенциально опасным оператором…

Зачем тогда вообще нужен !! ?

Представь, что ты — разработчик языка.
Для каких задач ты бы сознательно оставил такой инструмент?

Это вопрос не про правильно / неправильно и это не вопрос про Kotlin.

Это вопрос про дизайн языка, компромиссы и инструменты, которые он даёт разработчику.

Интересно почитать ваши мысли 👇

Мой 2020

Раскопал древние скрижали со времен давно минувших дней 🥹🥲😭

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

Фрагменты:

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

....

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

....

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

Читать полностью

Как я стал экспертом?

Ума не приложу как я стал экспертом (а главное в чём), но путь был тернист.

Выписал все свои должности, так, как они записаны в трудовой:

04.2011 - Консультант по продажам 💵
03.2012 - Старший лаборант межкафедрального компьютерного класса 🧪
11.2013 - Стажер разработчик 🔫
04.2015 - Младший разработчик 🧸
04.2016 - Младший разработчик 🧸
01.2017 - Тестировщик программного обеспечения 🪚
06.2017 - Тестировщик программного обеспечения 🪚
12.2017 - Разработчик программного обеспечения 👨‍💻
12.2020 - Инженер по разработке программного обеспечения 👨‍🔧
06.2022 - Старший разработчик 💻
04.2025 - Ведущий эксперт 🤪


Оказывается я почти в лаборатории работал, а еще быражил кредитками 😅

А как у тебя звучит самая зашкварная должность? 👇

Моя версия трекера

Ребят, всем привет, запилил свою версию трекера

Видос в облаке: https://disk.yandex.ru/i/SruF3E-Cst-GdQ

Видос на YouTube: https://youtu.be/DmcgvnUdFqc

Ссылка на репу: https://github.com/zor07/time-tracker

Карта проекта по разработке приложения для трекинга времени.

Задание 1

📄 Техническое задание

🔍 Ревью 1
🔍 Ревью 2
💻 Мое решение