Джавист Роман ☕️

Сколько должен длиться онбоардинг

Как правильно сделать онбоардинг

Тезисы по проведению 1-2-1

Друзья, всем привет ! Завтра буду на TeamLeadConf, кто хочет видеть истории оттуда, закиньте буста каналу: https://t.me/romankh3?boost

Как проводить свое свободное время и что приносит пользу для профессиональной деятельности Какие увлекательные моменты программист может обнаружить в своей жизни? Может быть, это интересные проекты, технические блоги, курсы обучения или что-то еще? Наверняка у каждого из нас есть какие-то вдохновляющие источники, которые помогли нам совершенствовать свои профессиональные навыки. В свое время для меня было открытием то, что во время посещения митапов по разработке можно было зарядиться огромнейшей порцией мотивации от таких же как и ты единомышленников. Посещение мероприятий стало для меня настоящим источником вдохновения. На таких встречах можно не только услышать отличные лекции и панельные обсуждения, но и завести новые знакомства с интересными людьми из индустрии. Это как катализатор для развития – чувствуешь, что ты часть огромного и творческого сообщества! Перебирая несчетное количество ресурсов с анонсами мероприятий натолкнулся на самый интересный и полезный, которым не стыдно поделиться — @Meetupochnaya. Никакой воды, только самые крутые мероприятия. Джавист Роман | Подписаться

Друзья, нужна помощь! Есть кто разбирается как правильно решить задачу по организации локальной сети в частном доме? Дано: 0. на входе будет оптоволокно с преобразованием в обычную витую пару 1. есть 10 проводов езернета, которые расходятся в разные части дома под свои нужды 2. есть два этажа в доме и нужен стабильный wifi сигнал, совсем уж хорошо будет если wifi будет бесшовный из вышеперечисленных проводов: - в рабочий кабинет, где должно быть преимущество в получении интернета - в домашний сервер, который также должен раздавать все из себя во внутреннюю сеть (то есть у него должен быть свой ip в сети) - два роутера для wifi, из которых еще будет соединение на принтер, умный дом и робот пылесос - провод на 4к телевизор - провод на проектор для просмотра кинчика. Что имею в логове? 1. нужен коммунатор, который бы связал бы это вместе 2. нужно несколько роутеров для wifi 3. нужны вполне себе нормальные настройки локальной сети, чтобы можно было ограничивать ресурсы определенные, выставлять наружу static ip для сервера наружу Не понимаю, какой лучше брать коммутатор. Смотрю сейчас на TP-link, отзывы не лучшие на них и на роутеры. Куда должен заходить интернет: в роутер вначале или в коммутатор, а потом дальше? Тоже не очень понятно. Хотелось бы в коммутатор и его держать как общую систему настройки всего. Но тогда не понятно что будет с ip-адресами в роутерах, что будут подключаться к коммутатору. Как-то сумбурно вышло, но вот что есть, заранее спасибо) Джавист Роман | Подписаться

Примета джуна #1 "С шашкой наголо" На фоне вопроса какая разница между джуном и мидлом пришла в голову идея пойти несколько другим путем - описать то, что в моем понимании есть признаки джуна. То есть те вещи, которые характеризуют джуна и могут быть маркерами как для тех, кто оценивает сотрудником так и для тех, кто хотел вырасти из джуна. Чтобы собрать их воедино - добавляю тег #примета_джуна. По нему можно будет все их собрать. Рассмотрим обычную историю: есть некий проект, который уже вышел в прод. Проект частично можно уже назвать легаси, так как некоторые модули от греха подальше не не лезут ибо "и так рабоает". На проект берут нового инженера с горящими глазами сделать мир лучше. Ему назначают задачу: нужно добавить еще один атрибут в одну из базовых сущностей. Задача в общем то не очень сложная, можно сказать даже идеальная для вхождения в проект - потому что придется пройти весь путь от добавления нового поля в таблицу до показа этого поля наружу через РЕСТ АПИ. И тут в ходе решения этой задачи наш инженер начинает по пути улучшать места рядом с которыми он находится. Небольшой рефакторинг там, небольшой рефакторинг сям. Там импорты поправил в соседнем классе, там удалил неиспользуемый уже долго метод. Создал удобочитаемые переменные вместо каких-то магических строк захардкодженных внутри. И казалось бы молодец, ведь проект после этого стал лучше и чище. Или нет? И вот здесь, прежде чем читать дальше, я предлагаю вам подумать самим. Хорошо ли сделал новый инженер или нет? .... Чтобы создать место между вопросом и ответом предлагаю вам подписаться на группу дискуссий к этому каналу: @romankh3_chat . Мы там всегда обсуждаем темы разработки. И, также подписывайтесь на мою библиотеку: @romankh3books Я там выкладываю свои купленные книги и другие, что попадаются мне и интересны. .... Думаю у всех уже было время подумать. Мой ответ НЕТ, человек не справился со своей задачей. Почему? Потому что вместо того, чтобы сделать только то, что ему говорят, он полез заниматься еще чем-то. Потратил лишнее время. А быть может эта новая функциональность уже ждет на ПРОДЕ и самодеятельность инженера оттягивает ее сдачу. Причем скорее всего этот рефакторинг будет носить локальный характер и не решит проблему целостно, а лишь только поверхностно. Очень сложно проводить код-ревью в таких случаях, так как нужно найти именно те изменения, что решают поставленную задачу. Выше я предположил идеальную ситуацию к рассмотрению, что дополнительная активность была по делу и ничего не ломала, а ведь это зачастую не так. А это значит, нужно еще больше тратить время на код-ревью, чтобы еще понять, что остальные изменения не сломают ничего и мы в следующем релизе не выстрелим себе в ногу на ПРОДе. А это все значит, что нужно будет проводить более детальную регрессию по тестированию, что опять таки нагружает команду без необходимости. Даже больше скажу, вполне возможно, что те улучшения не нужны были вовсе. Такое бывает сплошь и рядом. А работа произведена. Здесь конечно можно сказать, ну ты ж критикуешь, так предложил что можно сделать! Согласен полностью, такие вещи стоит обсуждать с командой и если в улучшениях есть необходимость, то нужно заводить отдельные задачи для этого и вести их в ракурсе работы с техдолгом. Оценили техдолг, отсортировали его по приоритетам и берем поэтапно в следующие спринты. Разумеется коллеги, жду ваше мнение в комментариях) Джавист Роман | Подписаться

Всем привет! Вы часто меня спрашиваете, куда я пропала (нет) 🤣 В прошлый раз вернуться я не смогла, потом оказалось, что у меня выгорание и пришлось из него выходить)) Про стадии выгорания, и что помогло мне из него выйти я обязательно напишу пост, а сейчас о другом) Коллега посоветовал классную книгу, «Фундаментальный подход к программной архитектуре» (обложку покажу в каментах), в ней описаны различные подходы к проектированию архитектуры, паттерны, антипаттерны и приёмы, виды архитектуры и др. Одна из глав книги посвящена такому понятию как записи архитектурных решений (Architecture Decision Record, ADR). Это созвучно с тем, что мы сейчас реализуем у себя в команде разработки, поэтому очень хочу рассказать) Architecture Decision Record - это текстовый файл, который создаётся для описания конкретного архитектурного решения. Мы у себя используем .md файлы и храним их в Git. Есть и другие инструменты и форматы, например, страница в вики вашей компании. Файл должен быть лаконичным, и содержать разделы, о которых я расскажу ниже. 1️⃣ Название - короткое описание архитектурного решения, должно быть информативным и понятным, чтобы быстро ориентироваться, о чём эта запись 2️⃣ Статуc ADR - на какой стадии находится данное арх. решение: принято, или ещё обсуждается (Request For Comments, RFC), а может заменено новым ADR 3️⃣ Контекст - ситуация, которая привела к созданию ADR и принятию решения 4️⃣ Решение - сама суть архитектурного решения и его полное обоснование. Важно уделить особое внимание именно обоснованию решения, ответить на вопрос «почему». Этот момент является ключевым и самым полезным (имхо) в документировании архитектуры 5️⃣ Последствия - описание того, что влечёт за собой принятое архитектурное решение. Какие плюсы и минусы у него есть, их анализ 6️⃣⭐️ Альтернативы - опциональный раздел, в котором сосредоточены альтернативные решения указанной проблемы, и причины, по которым эти решения не были приняты командой 7️⃣ ⭐️ Комплаенс - в книге рекомендуется включать этот раздел в свои ADR. Это описание, каким образом контролировать соблюдение требований данного арх. решения, должно ли это контролироваться вручную или можно автоматизировать. У нас пока такого раздела нет 8️⃣⭐️ Примечания - также опциональный раздел для указания автора, дат утверждения и замены, лиц, участвующих в принятии и утверждении данного решнеия и т. д. 9️⃣ ❓❓❓ 🔟 Вы великолепны 🤪😂 Вы спросите меня, зачем всё это нужно? И я вам отвечу))) 🌟 Это эффективный способ документировать архитектуру - всё в одном месте, можно наблюдать инкремент, описаны альтарнативы, + и - 🌟 Не приходится проводить повторные R&D, потому что результаты предыдущих архитектурных дилемм записаны, оформлены, подведены итоги 🌟 Чуть полегче онбордить новых разработчиков/внедрять иннерсорс, когда приходят с «а почему», можно прислать ссылку на «а потому» и вопрос исчерпан (но естественно пересмотр архитектуры и принятых решений должен быть) 🌟 Можно унифицировать подход к архитектуре микросервисов и тем самым снизить эксплуатационные издержки на поддержку Приземлю на конкретику. Если вы приходите в сервисы и не понимаете 🟢 почему условный Вася воткнул тут кафку, а не обошёлся рестом 🟣 почему решили использовать gRPC, а не десериализовать json’ы до талого)) 🔵 почему используется именно эта библиотека для генерации PDF 🟡 зачем тут Camunda прости господи))) 🟢 почему эту интеграцию реализовали из г… теми ресурсами, которые были доступны на тот момент 🥲 🟣 почему все сервисы развёрнуты в k8s, а один стоит на виндовой тачке в другом контуре Как я уже упомянула, мы у себя потихоньку начали внедрять практику написания ADR. Пока описано не всё, но уже сейчас удобно вспомнить какие решения мы приняли и почему решили именно так. Расскажите, знаете про такой инструмент? Практикуете?

Покрытие тестами и/или Как добавить JaCoCo в проект Gradle Чтобы спокойно спать по ночам разработчикам нужно писать тесты. Много тестов. И один из способов проверять себя - это следить за процентным покрытием тестами кода. В нормальном проекте, в котором есть время на их написание, обычно планка идет от 80% и выше, но не больше чем 95%. Здесь не нужно упарываться и доводить эту планку до 100%. Да, я знаю, что даже 100% покрытие тестов не гарантирует, что наш код оттестирован полностью. Но это и не цель - цель понимать, какое кол-во кода ВООБЩЕ НЕ ТЕСТИРУЕТСЯ. Это очень важный пункт и его нужно понимать. То есть если у нас покрытие 49%, то это значит, что в 51% кода тесты вообще не бывали и как там оно работает одному богу известно. А это в свою очередь гарантирует, что могут быть тривиальные дефекты, проблемы с рефакторингом и прочие "радости" побочки при отсутствии тестов. Самый быстрый и простой способ следить за этим - это добавить JaCoCo (Java Code Coverage) плагин. Он поможет нам в этом деле. Покажу на примере работы с gradle, благо там все просто. Нужно добавить следующую кодовую часть в build.gradle: В секцию плагинов добавить плагин JaCoCo:

plugins {
    ...
    id 'jacoco'
    ...
}

Далее еще настройки, коих по началу хватит с головой, чтобы решить эту проблему:

jacoco {
    toolVersion = "0.8.7"
}

test {
    finalizedBy jacocoTestReport
}

jacocoTestReport {
    reports {
        xml.enabled true
        html.enabled true
        csv.enabled false
    }
}

jacocoTestCoverageVerification {
    violationRules {
        rule {
            limit {
                // минимальное покрытие тестами в процентах
                minimum = 0.50
            }
        }
    }
}

check.dependsOn jacocoTestCoverageVerification

И все, теперь при запуске билда gradle clean build если покрытие будет меньше 50%, то выйдет ошибка такая:

* What went wrong:
Execution failed for task ':pprc-main-backend:jacocoTestCoverageVerification'.
> Rule violated for bundle pprc-main-backend: instructions covered ratio is 0.49, but expected minimum is 0.50

И все, дело в шляпе. Далее дело уже за вами. Разумеется всех желающих сказать свое мнение приглашаю в коменты) Джавист Роман | Подписаться

всех с пятницей, мастера поиска по интернету 😁

В чем разница между мидлом и сеньором Заметка навеяна вопросом друга на эту тему, решил развернуто ответить. Далее пойдут, разумеется, лишь только мои мысли, которые основаны на моем опыте. Специально перед написанием этой заметки решил ничего не читать в других местах, чтобы не замылить собственное ощущение. Приступим. В чем разница между мидлом и сеньором? Пройдем по пунктам: Зам тимлида Да, позиция сеньора означает, что он может быть потенциальным замом тимлида, Что это значит? - Это значит, что нужно будет понимать +- в целом архитектуру всего проекта - иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре. - При необходимости участвовать в совещаниях по планированию и интеграций - Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом - Уровень soft-skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому. Ответственность Здесь разница именно в том, что сеньор прежде всего должен уметь взять задачу / направление в развитии проекта и вести его до нужного результата. Понимать, что дальше с большой долей вероятности эта задача связана с человеком и придется за нее отвечать и далее. А это включает в себя процесс по переводу знаний другим коллегам, то есть уметь донести нормальным образом свои мысли до других. Техническая часть Разумеется техническая часть также важна. Сеньор должен иметь понимание как решить разные задачи, какие плюсы и минусы у конкретного решения и чем могут быть эти решения чреваты. Есть базовые пазлы разработки и они должны быть знакомы сеньору. Причем пусть даже какая-то из технологий не известна - это не страшно, всегда можно погрузиться настолько, насколько это нужно, чтобы начать перформить на должном уровне. Общий опыт работы За два года нельзя стать сеньором, разве что в каких-то фильмах, а не в реальности. Потому что опыт вещь такая, которую нарабатываешь с годами. Есть множество условностей и договоренностей как делать правильно, а как нет. И чисто физически их получить за короткий промежуток времени сложно, если вообще возможно. Зачастую это опыт не просто технический, а общий в разработке. Нужно знать и понимать что делать и как, нужно понимать круг своих обязанностей, нужно понимать и правильным образом ожидать от других действия. А это нарабатывается с годами. А это нельзя покрыть теоретическими знаниями и техникой написания алгоритмов и решением задач на литкоде. Это нечто большее. Это уверенность человека в своей правота, умение отстаивать свое решение. Вместо итога Резюмируя скажу, что это лишь мое мнение и мнение во время, пока я работал. Почему уточняю? Потому что определение лычек меняется всегда и нет каких-то точных черт, которые бы гвоздями прибили разницу эту. Джавист Роман | Подписаться

День ахуительных историй… Это диалог рекрутера с кандидатом, которого мы прособеседовади на мидла и выдали оффер

Зачем нужен лайвкодинг на собеседовании Есть за и против того, чтобы делать лайвкодинг на собеседовании и я также был скорее негативного отношения к этому, но вот недавно начал использовать такую практику в подборе. Почему против? Первое что приходит в голову- так это то, что времени на собеседовании всегда час - полтора и хотелось бы не тратить это драгоценное время. Потому как по-хорошему на это нужно 20-30% времени. И это действительно большой минус. Также у кандидата банально может не быть опыта лайвкодинга и он может показать себя в более худшем виде, чем он есть на самом деле. И вместе с тем я за, чтобы потратить время на это. Причем для собеседования от джуна до сеньора. Почему? На это есть несколько причин: Качество написания кода Вот здесь можно много говорить, но недавно мы отловили человека, который на Джаве писал названия м методов с большой буквы (!!!). Я думал, что таких вообще не бывает и это навеяло на мысль, что нужно сильнее присмотреться и с большей долей вероятности отказать кандидату. Знания ЯП Также всегда можно понять, насколько человек в курсе языка программирования. Вполне может быть, что человек занимался настройкой конфигураций и уже банально подзабыл саму джавку. Особенно это важно, когда участились случаи кандидатов, что прошли годичные курсы айтишные и хотят показать, что они уже нормальные мидлы. Обычно на такой практике их можно отловить. Как человек мыслит Каждый раз при собеседовании я хочу понять как человек мыслит - вывести его на разговор, в котором можно будет понять насколько человек рассуждает разумно. И вот как раз при создании алгоритма по решению задачи, а она действительно простенькая, как раз и видно как человек думает. Вместо итога И вот из-за этих пунктов я и думаю, что стоит это проводить. Причем причины и важность их разнится в зависимости от грейда кандидата, но оно того стоит. А вы что думаете? Как всегда всех неравнодушных жду в коментах!) Джавист Роман | Подписаться

Привет, друзья. Появилась опция по бусту канала, хочу тоже поучаствовать, чтобы поддержать канал, нужно премиум пользователям просто поставить свой голос: https://t.me/romankh3?boost

Друзья, хочу собрать свой сервер, нужен совет На фоне всех событий, я опять начал задумываться над собственным домашним сервером. Но в железе, к сожалению, я смыслю не очень. Нет у меня понимания. Какие цели? 0. Ubuntu server. 1. Nexcloud (сервер облачного хранилища работы работы до 20 пользователей). 2. Собственный репозиторий на примере GitLab + CI/CD с раннерами для них. 3. Медиасервер, на подобии Plex или чего-то похожего. 4. Сервер Библиотеки, для шаринга с другими, 5. Настроенная система backup/restote с соответствующей памятью под это и ПО. 6. Подключение своих пет-проектов. 7. Торрент-качалка (скорее всего хочется сделать как-то отдельно от основной машины, чтобы отсеивать проблемные вещи, быть может на малинке развернуть.) 8. Точка ВПН доступа для безопасного доступа к интернету во всех местах, где есть открытый интернет (также отдельно от основного сервера, скорее всего также на малинку). Что не понятно: 1. Не понятно какое железо лучше брать? 2. Какие жесткие диски брать? Сколько? 3. Как настроить бекап\рестор? 4. Брать готовый сервер или самому собрать его? 5. Как делить дисковое пространство? Нужно ли брать отдельно SSD для ОС, чтобы работа была быстрее? В общем как вы видите вопросов много, поэтому и интересуюсь у вас) Заранее всем спасибо за вашу помощь! Джавист Роман | Подписаться

удаленка удавка? За эти три года уже так привыкли все к удаленной работе. что кажется что в целом норм, можно. И даже не задумываешься, а было бы лучше из офиса? Воспоминания со временем стираются и навярняка сказать можно лишь оказавшись опять в офисе. Вот так и я, уже давно не бывал в офисе и не ощущал этой энергетики, пропитанной работой. Так уж случилось, что я смог выбраться "в люди" и посетить офис своей компании. Сижу уже несколько часов и балдею от того, как же здорово сидеть в красивом и уютном офисе, в котором так и хочется творить и делать что-то новое, интересное. Вид с 23го этажа так и пьянит и окрыляет. А вы что думаете по этому поводу, все-таки лучше встать с кровати, пересесть за стол и все, уже в офисе? Джавист Роман | Подписаться

true story ... У вашего продукта все отлично кроме одного - ему написали не мы (с) А сколько вы за свою работу написали своих реализаций валидаторов в проектах?...) П.С. мой счетчик перешагнул уже за 5 Джавист Роман | Подписаться

Что есть показатель хорошего митапа/конференции? …навеяно только что посещенным митапом. Как определить, был ли полезен митап/конференция? Я вот после оного задался этой целью и вывел для себя однозначный ответ: Если слайды из презентации хочется сфотографировать, если идеи, что доносят на докладах хочется как можно быстрее прикрутить у себя на работе или, если нет возможности на работе, сделать пет-проект, что обкатать технологию - то да, доклад был годный. А когда на митапе три доклада и после каждого из них такое ощущение - то это явный признак того, что все прошло великолепно. А вы что думаете, есть ли свои критерии? Джавист Роман | Подписаться