بسم الله الرحمن الرحيم
السلام عليكم ورحمة الله وبركاته
🚀 Запускаю телеграм-канал на тему бэкенд разработки
🗓 Планирую делиться контентом как на общие темы бэкенда, так и в частности на темы языка Go. Основной упор будет сделан на объяснение простым языком, потому что сложный я не знаю чтобы было понятнее большинству читателей.
🤲 Прошу АллахIа облегчить мне это дело и заложить для меня в нем благо в обоих мирах
И вся хвала принадлежит только АллахIу!

Немного о себе.

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

Спустя год, когда пора было уже выпускаться из ВУЗа и определяться с будущим, решил, что тестировать достаточно и пора писать код самому.

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

Что мы имеем на данный момент:
- 7 лет в IT
- из них почти 5 на бэкенде
- опыт работы как в мелких, так и в крупных компаниях
- на данный момент работаю в лучшей IT компании в России (по моей субъективной оценке)

Вполне достаточно, чтобы начать делиться опытом, согласны?

Джуны никому не нужны?

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

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

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

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

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

P. S.
Как минимум в 2х компаниях, где я работал, была практика найма и обучения джунов. Что-то мне подсказывает, что это определенная бизнес-модель, которая себя оправдывает. Не думаю, что такие компании перевелись.

السلام عليكم ورحمة الله وبركاته

Пока не хватает времени на продумывание программы постов, решил пойти по более простому пути.

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

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

Подумайте за меня и отпишитесь 👇

Проблемы на проде.

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

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

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

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

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

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

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

Спустя часов 6 одинокого расследования, я наконец-то нашел причину, хвала АллахIу. Я все не мог понять, как моя несчастная ветка привела к таким проблемам, при том, что я ее тут же откатил. На деле оказалось все куда хитрее.

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

Мораль:
- Бэкенд это нелегко, но интересно
- Не нужно паниковать, говори спокойно о проблеме, а там на деле может окажется что и косяк то не твой
- Если косяк коллеги, не торопись на это указывать, может следующий будет твой

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 простым языком