Top Alerts

Я уже не раз в своих постах затрагивал тему логов и метрик, чтобы донести на сколько важны они в системе. И возвращаясь к метрикам: какой топ самых распространенных алертов, которые должны быть настроены у каждого?

1️⃣ Availability - доступность сервиса. Или иначе: как много 5xx ошибок возвращается клиентам по сравнению с другими статусами.

2️⃣ Latency - как много времени сервису трубется для обработки одного запроса. Если оно становится больше, то это может свидетельствовать о каких-то внутренних неполадках (например, downstream сервис или база данных подтормаживают, SQL запросы не оптимизированы, и т.д.). Также это каскадно может привести к проблемам у upstream сервисов.

3️⃣ Traffic absence - отсутствие траффика вообще, когда ни одного запроса не достигает твоего сервиса на протяжении часа, двух, суток и т.д. Это свидетельствует о проблемах на уровень выше, в инфрастуктуре или на стороне клиента. Часто про этот алерт забывают, но он невероятно важен как и два предыдущих!

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

Учитель - это не тот, кто скажет тебе нечто, о чем другие до него не могли сказать. Учитель станет твоим другом, потому что скажет так, что ты наконец-то услышишь

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

Также очень сильно влияет то, КАК до тебя доносят информацию, используя уже известные тебе знания, термины, понятия и т.д. По-другому говоря, объясняют "неизвестное" через "известное".

Если же говорить про Java, то очень важно постепенно изучать ее по моему Roadmap, не пропуская какие-то темы. Даже если тебе, как ученику, кажется, что это не нужно и можно пропустить парочку курсов!

PS. Календарь настоящий, у меня дома на кухонном столе стоит 🙂

На Java сейчас в основном проекты на поддержке, а новые в сфере применения Java пишутся на Go или JS. Так ли это?

Начну с того, что когда я учился в университете БГУИР в далеком 2009 году, я всегда думал, что все вокруг меня пишут на C/C++. А значит и мне надо учить этот язык, чтобы устроиться на работу.

Потом я работал в компании Godel Technologies, где большинство проектов были написаны на C#, причем количество проектов этих только увеличивалось со временем, а проектов по Java уменьшалось здесь. И закрадывалась мысль, что вот-вот и C# поборет Java и нужно свичнуться на него побыстрее.

К чему это я?

А к тому, что нужно шире смотреть на вещи, а не на обстановку и людей вокруг тебя, потому что таким образом сильно сужается точка зрения. Но самое главное, что зачастую она не объективна и даже не верна (и это относится не только к программированию, а вообще ко всему).

Если хочется более объективной оценки, то лучше смотреть на вакансии в интересующем тебя регионе или на мировые рейтинги языков программирования, например, TIOBE или GitHub.

Лично я предпочитаю TIOBE, потому что он основан на анализе поисковых запросов по языку программирования, активности сообщества разработчиков, количестве вакансий и проектов. Он обновляется ежемесячно.

GitHub же не совсем объективен по моему мнению, потому что большинство компаний (тем более таких больших как MAANG) не держат там свой код. И, наоборот, студенты и фрилансеры активно его используют.

Также нужно обращать внимание на доменную область применения языка. Например, Python находится на первом месте в рейтингах потому, что сейчас нейронные сети и AI на хайпе. Но это не значит, что прикладные программы, enterprise, мобильные приложения и веб пишутся на нем с той же популярностью - это совсем не так. Эти области заняты другими языками.

Python - это обычно про data science и machine learning (и то он переписывается на C++, если нужно установить приложение на пользовательские устройства).

Что же касается изначального вопроса про Go - то, работая в компании Google, которая создала его, могу сказать, что он занял здесь лишь свою небольшую нишу. Так что до сих пор при выборе языка программирования для backend разработки новых сервисов - здесь предпочтительным является Java/Kotlin.

Теперь, напоследок, хочу добавить следующее:

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

Ровно неделя до старта менторства DMdev!

Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)

Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka

PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень

Самый младший студент на первой ступени менторства😁

Юбилейный 15ый старт двух ступеней состоялся 🎉

Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.

Спасибо каждому за доверие, let’s go 🚀

P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)

Отвечаю на #ВашВопрос
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?

Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.

На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.

Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:

// Это использование дефолтного маппера
public Optional<UserReadDto> findById(Long id) {
        return userRepository.findById(id)
                .map(userReadMapper::map);
}

// Это использование динамического маппера, переданного с контроллера
public Optional<T> findById(Long id, Mapper<User, T> mapper) {
        return userRepository.findById(id)
                .map(mapper::map);
}

А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.

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

Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.

Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.

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

#ВашВопрос
👇
Где лучше выбрасывать исключения? На уровне сервисов там где и основная бизнес логика или на уровне контроллеров?

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

1. Начнем с самого простого: ошибки базы данных нет смысла обрабатывать на уровне dao/repository, потому что в таком случае клиент даже не узнает, произошло успешное выполнение запроса и состояние сохранилось в базе или нет.

2. Пункт 1 ведет к тому, что ошибки обрабатываются на уровнях выше: service, controller, http filters, kafka consumers, etc. Поэтому вопрос становится следующий:

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

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

3. Если на пункте 2 мы и так находимся на последнем уровене, то нам придется принять решение о том, как обработать ошибку и какой вернуть ответ клиенту/пользователю.

Design Docs - очень мощное оружие!

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

Когда я получал какую-то задачу от своего team lead, я просто сразу принимался за написание кода. Конечно, уровень тех задач были далек от тех, что потом придется выполнять мне в будущем. Тем не менее, если я допускал где-нибудь ошибку, например, в схеме базы данных - то мне приходилось править в очень многих местах вверх по всей цепочке, начиная от sql скрипта и заканчивая сущностями, композиции классов, логики и тестов. Что занимало уйму времени.

А теперь представь, что ошибку допустили еще выше, где-то в архитектуре приложения. Сколько потребуется времени и человеко-часов, чтобы ее исправить или хотя бы залатать дыры с помощью всеми любимых "костылей"? В зависимости от уровня ошибки могут быть задеты не только твоя непосредственная команда, но и множество других команд, а также сами конечные пользователи, потому что приложение, например, может работать очень медленно или не работать вовсе.

Архитектурные ошибки обычно заметны не сразу, а с течением времени. Именно поэтому это так неприятно.

Чем на более ранней стадии получится найти ошибку при разработке ПО, тем дешевле обойдется ее решение

И самое эффективное средство здесь - это написание design docs. Т.е. в них мы можем быстро обсудить с другими программистами и решить проблемы еще до того, как была написана даже строчка кода. А значит, само решение занимает считанные часы или даже минуты: надо лишь подправить текст или перерисовать парочку диаграмм.

Так в моей работе сейчас ни одно сложное решение не обходится без написание design doc. Даже если проблема не столь велика, но имеет несколько возможных вариантов решений, из которых тебе не понятно как выбрать и хочется обсудить - то достаточно 1-2 страничного design doc, который мы еще называем 1-pager или 2-pager соотвественно.

#23 Мой путь

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

В то время на слуху у всех в Минске был сравнительно молодой район под названием “Новая Боровая”. Я сел за руль своего Polo и поехал на разведку. К моему удивлению, еще сидя в машине и подъезжая к “Новой Боровой”, я уже обратил внимание, что этот район сильно отличается от всех других: повсюду велосипедные дорожки, дома необычно окрашены, огромный рисунок Леонардо Да Винчи на всю стену, весь район разбит на закрытые небольшие кварталы по 5-6 домов в каждом, внутри которых был двор с беседками, барбекю, площадками для детей и спорта.

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

Когда подошел мой черед, и я начал беседовать с консультантом - пришло довольно досадное понимание. Во-первых, те квартиры, что мне понравились, еще в процессе строительства, которое займет около года. А значит нужно будет ждать их сдачи и продолжать платить за арендное жилье по 350$. Во-вторых, нужны будут деньги на ремонт, т.к. это будет новая пустая квартира без ничего вообще. В-третьих, мне придется отдать все деньги, что я скопил на тот момент. И в-четвертых, следующие 9 месяцев придется платить за ипотеку по 4000$ каждый месяц. На тот момент - это была моя зарплата в компании Synesis. Другими словами говоря, жить я буду только за счет курсов, что я преподавал в it-academy.

Это было довольно рискованным делом, но мое желание было слишком велико. Я сам по себе человек, который обычно быстро принимает решения. Помню, как моя будущая жена, с которой я еще не был знаком на тот момент, всегда удивлялась, как я, например, могу зайти в первый понравившийся магазин за шапкой и купить ее за 5 минут. А я просто не люблю все затягивать и долго размышлять над потенциально другими вариантами, которые могут мне понравится или могут быть лучше. Поэтому в этот раз тоже было не исключение - я согласился прямо в тот же день: выбрал квартал, дом, двухкомнатную квартиру в 59 квадратов на 2 этаже, и косметический ремонт. За все вышло чуть больше 83.000$.

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

#my_little_story

#ВашВопрос
👇
Денис, привет, спасибо большое за все что ты делаешь, развиваюсь благодаря твоим курсам очень сильно. Хотел спросить, как думаешь, через какое время нужно менять проект. Я уже два года на одном проекте, он развивается, все хорошо. Но может нужно какую то насмотренность тоже набирать или это ерунда?

Здесь нет однозначного ответа, когда стоит менять проект или компанию. Но как показывает статистика - это в среднем около 3 лет.

Я бы лучше акцентировал внимание на цели, которые ты приследуешь:

🎯 Если цель - это получить больше зарплату, то да, ты быстрее можешь повысить ее при смене компании (до какого-то порога на рынке или порога твоих профессиональных навыков).

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

🎯Если хочешь развивать свои навыки и не стоять на месте, то тут лучше прислушиваться к себе и чувству комфорта.

Развитие там, где ты чувствуешь дискомфорт, и чем он постояннее и сильнее - тем больше развитие. Но и утомление/выгорание тоже быстрее. В итоге твоя задача заключается в том, чтобы найти свой индивидуальный баланс между комфортом и дискомфортом.

О себе хочу сказать, что я пробовал разные варианты и разные "балансы". И пришел к выводу, что ощущения счастья и удовлетворение жизнью у меня уходили по двум причинам:

1️⃣ когда я начинал чувствовать себя очень комфортно. Наверное, природа наделила парней таким качеством, чтобы мы хотели развиваться, преодолевать себя и чего-то добиваться.

2️⃣ когда я чувствовал огромную нагрузку, или когнитивная сложность проекта/моих обязанностей была значительно выше моего приемлимого максимума.

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

PS. В моем случае, я нахожусь на одном проекте уже 2.5 года.

☝️Полный комплект из 13 курсов, которые будут участвовать в праздничной распродаже 18 марта

P.S. Среди участников будет разыграно одно место на менторство DMdev 1 ступени и две часовых консультации со мной

#ВашВопрос
👇
Подробный гайд или road map для senior java developer. Вот прям подробный, и который позволит не только пройти собеседование, но и выполнять задачи. К примеру знание Jackson библиотеки, sdkman, liquibase. Либо описание конкретных задач, разбитые на под шаги.

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

Senior Developer решает вопросы другого рода:

- как представить задачу бизнеса в виде технической дизайн доки

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

- предоставить оценки по времени реализации задач или всего проекта в целом (это самый ходовой вопрос у бизнеса, ибо их не интересуют твои фреймворки)

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

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

- писать правильные и хорошие алерты на критически важный функционал, чтобы узнать о проблеме на проекте как только она появилась

- брать на себя самые сложные/интересные задачи и реализовать их просто

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

Как можно заметить, довольно сложно провести собеседование на позицию Senior Developer и убедиться, что кандидат вам подходит.

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

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

- спрашивать об опыте на других проектах и чем занимался/что реализовавыл/с какими проблемами сталкивался

- попросить представить схематично как бы спроектировал бизнес задачу, и какие проблемные/узкие места видит здесь

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

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