А я тут рилсик запилил, и в мотиваторы подался 🌚

Я как-то снимал видос про докер на YouTube.

И недавно пришел чел, и сказал:
- Непонятно, поясни за эти файлы (см скрин)

А мне лень все это расписывать, тем более, что я когда-то делал урок на эту тему в своем курсе.

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

Урок в коментах.

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

Залетайте короче

Самый важный навык программиста.

Привет! В этом посте поделюсь своими мыслями по следующим вопросам:

1. Что самое сложное в работе программиста?
2. Какой скилл является самым важным?
3. Куда расти: вглубь или вширь?

В программировании способов реализовать какую-то задачу — вагон и маленькая тележка.

И представьте: собралась команда разработчиков, и им нужно реализовать какой-то большой проект. В этой команде могут быть как новички, так и древние мамонты. Новички учились по туториалам и никаких других способов реализовать задачу не знают. Ну а древние мамонты могут быть тоже разные. У одних расцвет сил пришёлся на времена Java 1.0, и в голове могут быть крутые, но чуть устаревшие знания. А могут быть и крутые мамонты, которые решают задачу элегантно: ты смотришь на их код и думаешь: «Боже, как круто! Как круто и непонятно».

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

Проект живёт, кодовая база растёт, люди уходят и приходят.

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

«Господи, что это такое?!»

Ты видишь столько кода и не понимаешь — это говно или так надо по объективным причинам. А если ты новичок, то смотришь на говно и думаешь, что это апогей алгоритмической мысли.

И если ты не сидел в проекте со времён распада СССР, то самым сложным в твоей работе будет одно:

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

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

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

Что же является самым важным?

Написать свой код так, чтоб спустя годы тебя не прокляли. А ещё лучше — чтоб не прокляли в тот же миг.
Тебе может показаться, что твой код проходит ревью, и, как бы, «старшие коллеги» берут часть ответственности на себя за то нечто, что породил ты в больном бреду, пытаясь понять, как оно всё тут принято. Но это далеко не всегда так. Ревью делают такие же люди как и ты. И ты будешь делать ревью и ловить себя на мысли, что хочется поставь аппрув "ради галочки", вроде бы все тут хорошо....

Если ты программируешь уже какое-то время и даже писал пет-проекты, то, возможно, замечал: возвращаясь спустя время к своим старым проектам, ты задумчиво чешешь свою репу и думаешь: «Господи, это же я писал, почему я ничего не понимаю?!». А это только ты, в маленьком проекте. Помножь эту ситуацию на бесконечность — и получишь некоторое (хоть и не полное) представление о том, что тебя ждёт, если ты не научишься писать код МАКСИМАЛЬНО ПРОСТО И ПОНЯТНО.

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

Как к этому прийти?
Нет быстрого способа. Нужно породить тонну говна и с опытом обрести понимание того, «что такое хорошо, а что такое плохо».

Ну и куда расти?

Знаешь, на свете есть столько всего помимо Спринга, что ты бы удивился. Такое многообразие разных решений: баз данных, брокеров сообщений, фреймворков. Что можно до пенсии пытаться освоить их все и так и не успеть сделать это.

Но это и не нужно. Благо, несмотря на всё это многообразие, под капотом везде заложены одни и те же принципы, которые придумали «когда наши родители были молодыми» люди, которые в разы умнее самого умного твоего знакомого.

Если у тебя получится хорошо (плюс-минус) разобраться в какой-то одной технологии, то освоить другие не составит большого труда. Поэтому моё имхо: не нужно бросаться учить всё подряд. Всё не выучить. И не угадать, что надо учить.
Сосредоточься на чём-то одном и долби в эту точку. А остальное поймёшь по ходу.

Всем добра, хорошей пятницы и прекрасных выходных!

Кто лучший программист (все еще), человек или машина?

Полное исследование можно почитать по ссылке.

Ниже перевод вступления

Генерация кода с помощью LLM (вместо написания кода с нуля) резко выросла в популярности. Однако последствия для безопасности такого кода остаются неизвестными.

Мы провели исследование, сравнив безопасность и качество кода, написанного людьми, с кодом, сгенерированным LLM, на широком наборе задач: структуры данных, алгоритмы, криптографические процедуры и задачи уровня LeetCode.
• Для оценки безопасности использовались модульные тесты, fuzzing и статический анализ.
• Для оценки качества учитывались сложность и размер кода.

Результаты:
• LLM может генерировать некорректный код, который не реализует требуемый функционал, особенно на сложных задачах. Ошибки могут быть тонкими.
Пример: реализация алгоритма SHA1 компилировалась, но была неверной.
• Даже если функциональность верная, код от LLM часто менее безопасен: отсутствуют защитные конструкции (defensive programming), что приводит к уязвимостям (переполнение буфера, переполнение целых чисел).
• Fuzzing показал, что код от LLM чаще подвержен зависаниям и крашам, чем написанный человеком.
• По качеству: LLM генерирует «скелетный» код без защитных конструкций, при этом более сложный на строку кода, чем человеческий.

Попытка улучшить:
Мы создали цикл обратной связи: просили LLM повторно сгенерировать код и устранить найденные проблемы (например, malloc overflow, выход за границы массива, null dereference).

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

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

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

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