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

По милости Аллах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 простым языком

Короткий совет вместо длинного поста:

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

Еще пример, когда это избавит от потенциальных багов. Имеем функцию

func getLesson(userId int64, lessonId int64) (Lesson, error)

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

Как можно было сделать лучше? Использовать элиасы:

func getLesson(userId UserId, lessonId LessonId) (Lesson, error)

При такой декларации перепутать аргументы уже куда сложнее 🙂

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