NFR.

NFR расшифровывается как Non-functional Requirements, то есть нефункциональные требования. Может показаться сложным, но если вдуматься, название хорошо отражает суть.

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

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

И есть нефункциональные требования (они же NFR), к которым, исходя из названия, можно отнести все остальные ожидания. Если с функциями все понятно, то что же тогда там за ожидания от НЕ функций, спросишь ты? А их оказывается может быть очень много.

Короткий перечень показателей, по которым могут быть NFR:
- Latency / Response Time - время ответа. То, за сколько твой сервер отвечает на запрос. Я, как заказчик, хочу узнавать время в Мекке за 200мс, а твоему серверу на подсчеты нужно 2 секунды - не пойдёт, прогиб NFR не засчитан.
- RPS (requests per second) - количество запросов в секунду. Твой сервер может отлично работать, когда его тестирует заказчик, но будет ли он работать, когда им начнут одновременно пользоваться тысячи людей?
- Errors Rate - процент ошибочных ответов. Если на каждый пятый (или даже сотый) запрос я получаю вместо результата неизвестную ошибку, это едва ли можно назвать стабильно работающей системой. Я (опять же как заказчик) хочу минимальное количество непредвиденных ошибок, например не больше 0,01% от общего количества запросов.

Это довольно краткий экскурс в тему, дабы было общее понимание, что это такое и зачем оно нужно. Надеюсь, было полезно. А ты слышал раньше про NFR?

Node.js — настоящий бэкенд?

Я попал на бэкенд через Node.js. Довольно легко освоил и приступил к работе. Два года мы разрабатывали заказные приложения разного типа и не испытывали никаких ограничений языка, то есть казалось бы все отлично. Но, задумываясь о своей дальнейшей карьере, я испытывал беспокойство. И дело все в том, что я нередко слышал, что Node.js это не настоящий бэкенд.

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

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

И тут один коллега переходит в Яндекс. Первые мысли были: «Раз в Яндекс берут моего коллегу, значит там используют ноду на бэке, и значит могут взять и меня». Однако спустя время, слышу отзыв того коллеги, что он занимается каким-то сервисом-прослойкой между фронтом и другим, (настоящим) бэкендом, от чего он не сильно в восторге. Прогиб не был засчитан.

Всех ситуаций я уже не вспомню, но решающей наверно была следующая. В статьях о крутости Node.js в то время (а судя по гуглу и сейчас) упоминался Netflix как пример компании, использующей бэкенд на ноде. В Нетфликс я конечно не планировал, но это сильно обнадёживало, все таки это одна из крупнейших IT компаний. Эта мысль была как спасательный круг, к которой я часто возвращался. И вот однажды, наткнувшись на интервью российского программиста в Netflix, на вопрос о стэке технологий, я слышу, что помимо плюсов в компании очень много джавы и, цитата: «на удивление есть люди, которые пишут на ноде. …Прям на ноде, в продакшене». С интонацией и мимикой при этом можете ознакомиться сами.

Последний оплот был разрушен, я начал искать другие варианты, и остановился на Golang. Милость АллахIа велика, очень скоро Он предоставил мне вакансию в компании, где требовался человек со знанием ноды и желанием перейти в Go, потому что компания выросла и переписывала свой код с Node.js на Golang. Я перешёл на го и беспокойства относительно языка были закрыты (الحمد لله).

У ноды много преимуществ, о которых вы и сами можете почитать в интернете. Это очень крутая технология, которая отлично справляется со многими задачами и может служить более простым стартом для будущих бэкендеров. Однако могут быть нюансы, о которых я рассказал. Поэтому, если перед вами стоит такой выбор, хорошо все взвесьте, определите, что для вас важнее сейчас и в будущем, и исходите из этого. И не забудьте сделать по итогу Истихару и положиться на АллахIа!

Monitoring & Alerting.

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

- Monitoring - возможность в любой момент понимать (мониторить) состояние нашего бэкенда: сколько приходит запросов, за какое время они обрабатываются, сколько из них падает с ошибкой и т.д.;

- Alerting - оповещение (максимально оперативное) об аномальных изменениях этого состояния: если резко повалило много запросов или ошибок, нам нужно об этом узнать как можно раньше;

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

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

Надеюсь, было полезно. Кстати, в каком состоянии сейчас твой бэкенд? ;)

Health Check и alerting на коленках.

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

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

При реализации первого пункта обычно используется паттерн Health Check. Если коротко, в приложении создается ручка*, которая внутри проходится по всей критически важной инфраструктуре (доступна ли база или еще какие зависимости), и отвечает статусом работы сервиса. Но раз у нас все на коленках, мы можем взять просто самую популярную ручку и использовать ее в качестве проверки работоспособности сервиса. Ответила без ошибок - значит все работает.

Осталось дергать эту ручку с какой-то периодичностью для проверки статуса. Тут нам поможет сервис UptimeRobot, который готов делать это за нас каждые 5 минут совершенно бесплатно (хочешь чаще - придется заплатить).

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

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

Если было полезно, с тебя репост.
________________
*Ручка - популярный синоним эндпойнта API.

@Backend простым языком

Common practises.

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

Ситуация: человек в коде идет циклом по массиву. Ему на ревью предлагают переменную с индексом текущего элемента переименовать в i, как это повсеместно принято. На что он отвечает, что i уже есть, а это внутренний цикл. И дальше голова сама подсказывает, что тогда тут должно быть j, потому что это тоже повсеместно принято. Если у тебя идут вложенные циклы, то их индексы сначала называешь i, дальше j, а затем k, так уж повелось (видимо из математики). Но что-то пошло не так, и человек вспоминает, что j он оказывается "с универа не любит". В итоге он называет "а", и дальше где-то посреди кода, где ты можешь уже забыть про всякое "а", ты видишь условие if (a == 0) и гадаешь, что же это такое. Этот пиар уже замержен, но я конечно попросил исправить название на j в другом пиаре.

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

________________
@Backend простым языком

Уровни программистов

Эта тема вызывает не мало споров (а также шуток). Тут тоже будет лишь субъективное мнение автора.

Чаще всего программистов делят на 3 уровня:
⁃ Junior
⁃ Middle
⁃ Senior

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

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

Есть один очень упрощенный, но притом не далекий от реальности способ. Нужно посмотреть на то, как тебе ставят задачу на работе:
⁃ Junior - тебе расписывают, «что» сделать и «как»
⁃ Middle - тебе описывают, «что» сделать, а «как» ты разберёшься сам и сделаешь это хорошо
⁃ Senior - ты нередко сам предлагаешь, «что» нужно делать и «как»

Дело не в том, сколько лет у тебя опыта, какие курсы прошел и красивые слова указал в резюме. Твой уровень определяется многими факторами, к которым можно отнести объем ответственности, которую ты берёшь, ценность, которую приносишь бизнесу и самостоятельность.

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

Спойлер: это не единственная шкала уровней программистов и в других постах мы поговорим о более прозрачном и многоуровневом подходе إن شاء الله.

Что думаете, синьоры помидоры?
______________________________
@Backend простым языком

На канале затишье?

По милости АллахIа в жизни очень много всего и руки просто не доходят. Из основных направлений сейчас это собственная кузня бэкендеров @devsimulator, опыт обучения оффлайн получается довольно интересным. إن شاء الله из этого выйдет польза для меня и учеников.

Но это не значит, что канал заброшен, так как свыше ста подписчиков это уже ответственность. Я продолжу писать дальше, сильно не затягивая إن شاء الله

Ну а пока читать нечего, можно посмотреть выступление про софт скиллы
https://youtu.be/1l6FOV4ePlM

Профили инженеров

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

Первой проблемой классического подхода я озвучивал недостаточное количество уровней для такой сложной профессии. По новой системе уровней целых 8 (от E1 до E8). Если проводить аналогию, инженеров Е1-Е2 можно отнести к джунам, Е3-Е4 к миддлам, Е5-Е6 это синьйоры, а выше уже некие эксперты.

Остается вторая проблема - определение уровня. Для этого в компании выделили 7 направлений оценки и требования по этим направлениям, которые ожидают от программиста на каждом из уровней.

Для примера часть требований к уровню Е4:
- Экспертность
- Декомпозирует задачи. Умеет оценивать технические риски. Предлагает меры по их смягчению или устранению.
- Работает с неопределённостью, например открытыми задачами в своей области ответственности. Понимает, что нужно сделать, но может не понимать, как.

- Инженерная культура
- Даёт содержательные комментарии на Code Review.
- Находит баланс между скоростью и качеством разработки/тестирования.

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

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

С полным списком требований для всех уровней можно ознакомиться по ссылке.

Как вам такая система оценки?
______________________________
@Backend простым языком

Аккуратнее с errgroup.

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

Обычный пример:

// здесь выше какой-то код, у которого есть контекст уровня запроса к серверу
…
// создаем errgroup с контекстом, чтобы связывать горутины между собой и при ошибке в одной из них, валить остальные, не дожидаясь их окончания
eg, ctx := errgroup.WithContext(ctx)

// запускаем несколько горутин
eg.Go(func() error {
    var err error
    images, err = getImages(ctx)
    return err
})

eg.Go(func() error {
    var err error
    books, err = getBooks(ctx)
    return err
})

// дожидаемся их выполнения
err := eg.Wait()
if err != nil {
    return err
}
…
// идем дальше использовать контекст

Кто скажет, что не так с этим кодом?

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

func (g *Group) Wait() error {
    g.wg.Wait()
    if g.cancel != nil {
        g.cancel()
    }
    return g.err
}

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

eg, egCtx := errgroup.WithContext(ctx)

Натыкались на эти грабли?
______________________________
@Backend простым языком

SQL-лайфхак.

Реальная задача с одного из проектов (немного упрощена для понимания):

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

CREATE TABLE user_lessons(
    user_id INTEGER NOT NULL,
    lesson_id INTEGER NOT NULL
);

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

user_id | lesson_id 
   1233 |      12 
   2645 |      12
   5823 |      13
   5823 |      14
   3123 |      18

Для пользователя 1233 запрос должен был вернуть 13, 14, 18, потому что эти уроки он не проходил.

Первое, что приходит на ум, это сделать подзапрос

SELECT DISTINCT lesson_id from user_lessons where lesson_id NOT IN (
    SELECT DISTINCT lesson_id from user_lessons where user_id = 1233
)

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

В процессе решения я все никак не мог вспомнить лайфхак для таких случаев. Точно помнил, что он есть и даже в чем его примерный смысл, но не хватало последнего элемента пазла. Что делать в таких случаях? Расчехлять GPT, на этот раз китайский - без регистрации, смс и VPN.

Первым делом он тоже предложил подзапрос, но услышав в ответ how about not using subquery?, выдал необходимое решение 🎯

Кидайте свой вариант решения без подзапроса в комменты или смотрите лайфхак ниже:

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

SELECT DISTINCT lesson_id from user_lessons ul1
LEFT JOIN user_lessons ul2 on ul1.lesson_id = ul2.lesson_id AND ul1.user_id = 1233
WHERE ul2.user_id IS NULL

______________________________
@Backend простым языком

Нотации.

Краткий ликбез по нотациям - способам именование пременных, папок и тд - в программировании.

Самые популярные, их название и одновременно пример:
- camelCase
- snake_case
- PascalCase
- kebab-case

В Golang (да и везде) в коде обычно используется camelCase. Для наименования файлов и папок мы в команде используем snake_case.

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

______________________________
@Backend простым языком

PostgreSQL timestamp.

TL;DR Всегда используйте для дат timestamp with time zone

Ситуация: В базе есть колонка updated_at, тип которой timestamp, а значение по умолчанию CURRENT_TIMESTAMP.

Проблема: Вычитываем значение этой колонки, сравниваем с time.Now(), и оказывается, что в колонке лежит время +3 часа по сравнению с тем, что дает гошный time. То есть в часовом поясе Москвы, притом без указания таймзоны, что лишает нас возможности перевести time в ту же часовую зону для корректного сравнения времен.

Неожиданно оказалось, что CURRENT_TIMESTAMP при конвертировании в timestamp сохраняет текущее время не в UTC, как можно было бы ожидать, а в часовом поясе клиента, который инициировал запрос (теряя при этом инфу о таймзоне). А если клиентский он не знает, то в часовом поясе сервера, на котором он находится.

Решение:
- Если у вас маленькая база, то накатить миграцию с изменением типа колонки
- Если база большая и не хочется мучаться с аккуратным переездом на новый тип, при сохранении даты явно указывать таймзону timezone('UTC', CURRENT_TIMESTAMP)
- В будущем всегда использовать timestamp with time zone

______________________________
@Backend простым языком

Хочешь добавить прогон юнит-тестов в гитлабе при создании мерж-реквеста и подозреваешь, что джоба не будет падать, если тесты не прошли
Раньше:
- Гуглишь, копаешься на стаковерфлоу, страдаешь - минимум минут 10 и больше
Сейчас:
- Спрашиваешь GPT, получаешь ответ - менее минуты (остальные 9 пишешь об этом пост в канал)

______________________________
@Backend простым языком

Отложенный выстрел в ногу в SQL

Нашел в коде примерно следующий запрос:

SELECT books.id,
img_url,
name
FROM books
JOIN authors ON books.author_id = authors.id;

То есть получаем айдишники книги, их картинки и имена авторов, которые хранятся в другой таблице. Запрос рабочий, вроде нет проблем, да? До поры до времени.

Сегодня он рабочий, потому что колонка img_url есть только в таблице books, а колонка name только в таблице authors. А вот айдишник есть в обеих таблицах, поэтому мы были вынуждены прописать явно из какой таблицы его брать.

Завтра (или через год) коллеге прилетает задача, что у авторов тоже есть лицо и мы хотим сохранять в таблицу их картинки. Он смело идет и первым делом добавляет в таблицу authors колонку img_url, а далее раскатывает на прод, ведь что можем быть безобиднее, чем просто добавить никого не трогающую новую колонку.

Но не тут то было. В другом конце кода лежит заряженный SQL запрос, который только и ждет, когда спустят курок. С добавлением в таблицу authors колонки img_url, наш запрос выше сломается, так как теперь неясно, какая именно колонка img_url в нем подразумевается. По итогу запрос будет выдавать ошибку ERROR: column reference “img_url” is ambiguous

Мораль: если вы в запросе джойните таблицы, всегда в селекте указывайте, откуда брать каждую из колонок

Запрос на предохранителе👇

SELECT b.id,
b.img_url,
a.name
FROM books b
JOIN authors a ON b = a;

______________________________
@Backend простым языком

Tab-chaos.

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

Все очень просто: ограничьте в редакторе количество активных вкладок до одной. Как говорил Брайан Трейси: “Я обещаю, это изменит вашу жизнь”. Больше не придется постоянно контролировать этот таб-хаус, клацать “Close other tabs”, искать среди тысячи открытых ту самую. Одна активная вкладка в один момент времени. Все.

А как же тогда находить предыдущие вкладки?
Множество открытых вкладок не сильно помогает в решении этой проблемы. К предыдущим можно вернуться через cmd+tab, но еще лучше настроить хоткей на возврат к предыдущим/следующим положениям курсора - еще один маст хэв в работе.

______________________________
@Backend простым языком

Делюсь с вами крайне полезным инструментом, который судя по всему далеко не нов, но умудрялся обходить меня стороной. PlantUML - (грубо говоря) язык разметки, который позволяет текстом описывать разные диаграммы (sequence, activity, etc.) и генерить их представление с помощью плагинов. Особенно незаменимая вещь в крупных компаниях, где ценится документирование своей работы и в целом подобные артефакты.

Как начать пользоваться:
- Кидаете кусок кода в chatGPT с запросом generate me plantUML sequence diagram for code below
- Сохраняете результат к себе в проект и редактируете под нужды
- Profit

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

______________________________
@Backend простым языком

Какой язык программирования выбрать бэкендеру или почему я советую golang? Часть 1.

Осторожно: Статья супер субъективная. Когда ты пишешь на каком-то языке, создается ощущение, что весь мир крутится вокруг него, а остальные языки умирают (кроме php, там мир тебе напомнит, как обстоят дела), поэтому объективным быть в данном вопросе тяжело.

Теперь по поводу Golang. Предлагаю определиться с основными требованиями при выборе языка программирования. На мой взгляд от языка ожидается, чтобы:
1. Он приносил деньги - количество вакансий, уровень зарплат
2. Его относительно легко можно было освоить - обучающие материалы, курсы, отсутствие исторической нагроможденности языка ненужными возможностями
3. Был современным - тут тоже можно смотреть на вакансии, отсутствие жестких ограничений, использование крупными компаниями

______________________________
@Backend простым языком

Какой язык программирования выбрать бэкендеру или почему я советую golang? Часть 2.

Golang как по мне отлично подходит по всем пунктам:
1. С деньгами проблем нет, за него платят как минимум не меньше, чем за конкрутентов. Количество вакансий по ощущениями только растет.
2. Язык изначально заточен под легкость освоения, эта цель стояла у истоков его создания. Он сильно ограничен по количеству ключевых слов, притом не в ущерб возможностям. Есть проблема, что в русскоязычном пространстве ты не найдешь тонны курсов на любой вкус, но это может быть и плюсом.
3. Go создан в 2009ом году, то есть является довольно молодым, притом прогрессивно развивающимся языком, за которым стоит IT гигант Google. В пользу его современности и в целом главным аргументом для меня является то, что крупные компании переходят на него с других языков. Я думаю не нужно быть техническим директором, чтобы понимать: если крупная компания принимает решение о выборе нового основного языка, это должно быть чем-то крайне обоснованным и перспективным, так как сулит большие затраты и риски. Список компаний, ныне использующих Golang можете найти в поисковике, но вот короткий список известных мне компаний, перешедших на него:
- Авито - с PHP на Golang
- Wildberries - с C# на Golang
- Goods (ныне МегаМаркет) - c Nodejs на Golang

Решать в конечном счете вам самим. Главное помнить, что язык это только инструмент, его можно сменить в любой момент, и не стоит думать, что это выбор на всю жизнь.
______________________________
@Backend простым языком