Когда джун совсем без присмотра

Невыдуманные истории

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

Сразу опущу вводную часть с проверкой конфигураций и прочим (оно на самом деле важное, но пожалуй в другом посте или видео объясню). По мониторингу (это тоже отдельная тема для разговора) нашел очень интересную штуку - один эндпоинт был со средним временем ответа порядка 3-4 минут (для реста это ну очень много и выходит за рамки дозволенного). Копаясь в коде я обнаружил некоторые изменения, которые как раз были сделаны и одна из заглушек возвращала

return new CompletableFuture();

а дальше по коду просто была попытка получить результат выполнения через get().
Попробуйте предположить какая же здесь кроется проблема, не заглядывая дальше по тексту.
А проблема вот в чем - эта самая фича не имеет результата, а следовательно будет висеть пока поток кто-то не прервет для прекращения ожидания, как итог получаем множество потоков, которые просто встали в ожидании пока завершится та самая фича.
Как это можно исправить - использовать статические методы (с передачей результата выполнения в метод)

CompletableFuture.completedFuture(U value);
CompletableFuture.failedFuture(Throwable ex);

Полезный контент не заходит? Ловите мемчик

https://youtube.com/shorts/aHJrmeBvQeM?feature=share

Уже завтра он встретит вас на работе

Попробовал я значит эти разрекламированные сегодня тесты на форуме ЦИПР (это же надо додуматься, чтобы на такой уровень вынести 10-20 - минутные тесты для разрабов как вау-технология).

Краткий итог - шлак полнейший - теоретические вопросы еще более-менее, но практика с ужасным редактором кода, который даже не умеет в автокомплит - это фиаско (на самом деле то ли тормозит, то ли частично умеет). Кроме того - задачи элементарные, но с кучей условий, что ты можешь не успеть вспомнить все нужные статические методы, которые на практике не часто используешь, вроде parseDouble, Math.pow. Вообще эта часть похожа на алгоритмическую секцию в одной известной компании на "Я" - сидишь как дурак и пытаешься доказать, что ты - не верблюд.

Кто пытался - кидайте в комменты свои впечатления!

У вас как дела с ИИ обстоят?

Никогда такого не было и вот опять

Вот так придумываешь мемчики, набираешь просмотры, а видео потом блокируют. Я конечно понимаю, что авторские права, но это копеечный отрывок

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

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

Немного про практику. 💻 Технический дневник.📒

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

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

В пользу поста выше. 👆

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

Как думаете заметят такой профиль в гитхабе?

Количество или качество 🤔

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

Попытка успеть многое в ущерб качеству решения задачи приводит к большему количеству дефектов, иногда даже очень и это только то, что находится на поверхности при тестировании фичей и обнаруживается на раннем этапе. Бомбы замедленного действия могут сработать в самый неподходящий момент, и решение последствий привести к громадным затратам ресурсов (на такое даже есть статистика в умных книжках).

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

Встречайте - теперь это транслируется и на хх. Что думаете?

Есть такое?

Аларм! В закрепе есть полезные материалы. Как напоминание тем, кто вдруг забыл или не знал.