@davidobryakov

Оптимизация работы эндпоинта

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

Одну такую фичу я завёз на продакшн около полутора месяцев назад, а на этой неделе наконец-то дошли руки до оптимизации.

Проект ещё только находится на пути к выходу из MVP, но уже имеет несколько активных клиентов, данные которых прилетают к нам на сервера 24/7.

Кратко о сути проблемы:

- мне надо было динамически рассчитывать статус текущего состояния некой установки, этих установок может быть несколько;
- в первой итерации статус рассчитывался через python и сохранялся в БД в момент совершения запроса на его получение.

Путь улучшения перфоманса выглядел так:

- я отрефакторил всё вручную и ускорил работу метода с 30 секунд до 12 секунд;
- я сходил в GPT, он отрицательно ускорил метод с 12 секунд до 20 секунд;
- я начал делать фоновый предрасчёт через celery и сократил тем самым работу метода аж до 68мс;
- количество данных в БД увеличилось (за 3 дня насоздавалось свыше 40 тысяч записей со статусами) и работа эндпоинта замедлилась до 40 секунд;
- я начал записывать результат предрасчёта в redis и вновь вернул время работы к значению в районе ~100мс.

Как можно было бы решить это иначе?

Вынести предрасчёт на уровень postgres (в другом месте этого же проекта уже есть view, которая динамически рассчитывает некоторые показатели), но поскольку накручивать триггеры в БД я не очень хочу, а сохранять новые статусы для истории и обновлённой инфографики может быть важно, было принято именно то решение, о котором я написал выше.

Какой вывод я для себя сделал?

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

Настраиваем автодокументирование для express-приложений

Читать полностью: https://blog.kantegory.me/express-autodoc

Долгое время в express было принято использовать решения, которые довольно большую часть работы перекладывают на разработчика. Одним из самых популярных решений и по сей день является swagger-jsdoc.

Поскольку, оно является и самым проверенным, я продолжал рассказывать о нём студентам из года в год. Но в этом году что-то пошло не так... Один из студентов спросил: "а нет ли чего-то такого же удобного, как в Nest.JS?". Тут-то всё и началось.

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

swagger-jsdoc

Пример кода:

/**
 * @openapi
 * /v1/testCreate:
 *   post:
 *     produces:
 *       - application/json
 *     parameters:
 *       - name: username
 *         in: formData
 *         required: true
 *         type: string
 *       - name: password
 *         in: formData
 *         required: true
 *         type: string
 *     description: Test create
 *     responses:
 *       200:
 *         description: Returns a created object.
 */
router
  .route('/testCreate')
  .post(exampleController.post)

Полный код примера доступен на github.

Плюсы:
- простота
- универсальность

Минусы:
- много ручной работы

routing-controllers

Пример кода:

@JsonController()
export class ExampleController {
    @OpenAPI({ summary: 'Test create' })
    @ResponseSchema(TestCreateResponseDto, { statusCode: 200 })
    @Post('/testCreate')
    post(
        @Body({ type: TestCreateDto }) body: TestCreateDto,
        @Res() response: Response,
    ): void {
        const uuid: string = randomUUID();

        const responseBody = {
            uuid,
            ...body,
        };

        response.status(201).send(responseBody);
    }
}

Полный код примера доступен на github.

Плюсы:
- код более структурирован
- вынужденное использование валидаторов
- синтаксически близко к Nest

Минусы:
- проблема с рантаймом tsx
- остаётся ли express всё ещё таким же лёгким?

tsoa

Пример кода:

@Route()
@Tags('Example')
export class ExampleController extends Controller {
    @Post('/testCreate')
    @Response<TestCreateResponseDto>(201, 'Returns a created object.')
    public async post(
        @Body() body: TestCreateDto,
    ): Promise<TestCreateResponseDto> {
        const uuid: string = randomUUID();

        return {
            uuid,
            ...body,
        };
    }
}

Полный код примера доступен на github.

Плюсы:
- код более структурирован
- встроенная валидация
- комплексное решение
- синтаксически близко к Nest

Минусы:
- остаётся ли express всё ещё таким лёгким?

Выводы

Сухое сравнение доступно на npm-compare. По моим личным ощущениям, tsoa — самый оптимальный вариант.

Читать полностью: https://blog.kantegory.me/express-autodoc

Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

#чтояпрочитал #микросервисы

Ссылка на оригинал: https://habr.com/ru/articles/904954/

Краткая выжимка

Strangler fig (удушающее дерево) — подход, при котором создаётся некий фасад, изначально перенаправляющий запросы в монолит. По мере реализации микросервисов, перенаправление запросов переключается на них. Процесс повторяется, пока монолит не будет полностью вытеснен.

API Gateway (API-шлюз) — точка для аккумуляции и последующего распределения пользовательских запросов по сервисам. По сути, он и является тем самым фасадом, который может помочь в случае использования паттерна Strangler fig.

API Gateway делят на несколько шаблонов:

- Routing — шлюз выполняет функцию маршрутизатора, прокси
- Aggregation — шлюз агрегирует данные: получая один запрос от клиента, ходит в несколько сервисов, возвращает клиенту единый ответ
- Offloading — шлюз берёт на себя ряд общих задач для сервисов (например, авторизация, логгирование, etc.)

На практике, API Gateway часто совмещает все эти роли.

Service Mesh — архитектурный паттерн для организации умной сетевой прослойки в микросервисной архитектуре. По сути, это распределённая система прокси-серверов, сопровождающая каждый из сервисов. То есть, у каждого сервиса появляется свой прокси под боком. Нужно это для того, чтобы снять с микросервисов необходимость реализации логики для балансировки, шифрования, отслеживания метрик и так далее.

Sidecar — это паттерн, предлагающий вынесение неосновной логики приложения в отдельный контейнер, запускаемый рядом с основным сервисом. Например, логгирование, конфигурация, связи с внешними системами. Это позволяет повысить модульность вашего приложения.

Database per Service — паттерн "база данных на сервис".

CQRS (Command Query Responsibility Segregation) — паттерн, разделяющий ответственность за изменение состояния и чтение состояния приложения между разным компонентами или моделями. По сути, это про использование двух БД для одного сервиса: одна БД для записи, другая для чтения.

Event Sourcing — паттерн хранения состояния системы, при котором каждое изменение состояния сохраняется, как отдельное событие. По сути, мы храним историю изменений каждого объекта в виде списка событий.

Выводы

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

Поиск мотивации в скучных задачах

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

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

Настоятельно рекомендую, буду пробовать применять в своей работе.

Ссылка: https://habr.com/ru/articles/906258/

Переход с Python на Go и мысли о высшем образовании / ч. 3

Пост в блоге: https://blog.kantegory.me/it-education

Мысли об онлайн-школах и преподавании

В то же время, как альтернатива 4-6 годам в вузе, на рынке уже давно существует предложение пройти курсы на 3-18 месяцев и стать готовым специалистом. Некоторые даже говорят, что сделают вас middle-разработчиком (это просто маркетинг, не ведитесь).

Закономерным итогом обучения в онлайн-школах является неадекватная накрутка опыта в резюме и полное отсутствие фундамента для становления специалистом. Пишу это на примере моей текущей ученицы, с которой мы уже более двух месяцев занимаемся. Я не спрашивал, сколько стоило её обучение, но итоговый результат отталкивает. Да, что-то в её голове действительно отложилось, но крепкого фундамента по фронтенду не было сформировано. Мы более двух месяцев мусолим ванильный JS, HTML, CSS, чтобы освоить общие концепции и не запираться в одном react. Иметь гибкость. Уметь ориентироваться.

В среднем, на выходе из онлайн-школы, мы имеем человека, который не умеет подстраиваться и адаптироваться под возникающие условия. Конечно, всё индивидуально. Почти наверняка есть люди, которые прошли курсы, но при этом самостоятельно получали и дополнительную информацию из различных источников. Их опыт может отличаться. Да и в вузах преподаватели далеко не всегда мастера своего дела. Мы тоже можем ошибаться. Более того, мы регулярно это делаем. Но ошибаться - это не страшно. Главное, чтобы студенты ничего не поняли в итоге получили корректную информацию.

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

Но вернёмся к критике онлайн-школ и их общей проблеме. Подведём итог.

Выводы

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

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

Переход с Python на Go и мысли о высшем образовании / ч. 2

Пост в блоге: https://blog.kantegory.me/it-education

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

Блистательное утверждение, орфография автора сохранена:

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

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

Итог этого поста вполне очевиден и закономерен, - его заминусовали на хабре. В комментариях пишут:

Но больше всего мне непонятен посыл статьи.

Судя по приведенным примерам, вам и в питоне пока многое не понятно.

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

может скажем ему?

Мысли о второй статье

Очевидно, что автор имеет опыт работы и понимает то, о чём он пишет. В некоторых моментах он даже довольно глубоко копнул, когда писал про запуск golang-кода внутри python (в виде собранной библиотеки, конечно).

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

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

Мысли о высшем образовании в IT

Возвращаясь к моим мыслям о первой статье:

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

Является ли при этом высшее образование панацеей? Нет, не является.

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

Если же мы говорим о высшем образовании в IT, то именно благодаря высшему образованию, формируется та самая "база", к которой довольно часто относят и знания в Computer Science.

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

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

Переход с Python на Go и мысли о высшем образовании / ч. 1

Пост в блоге: https://blog.kantegory.me/it-education

Предисловие

Уже около года в моих черновиках для постов гуляет заметка с названием "для чего нужен вуз?". Разумеется, с точки зрения IT. До сегодняшнего дня, там была только одна мысль, которую я подметил, когда писал в дневник:

Осознал, что вуз нужен в том числе для того, чтобы научиться писать отчёты по стандартам, да и в целом делать что-либо с учётом принятых стандартов.

Сегодня я гулял по хабру и наткнулся на две похожих статьи об одном и том же, но от разных людей: "Переход с Python на Go: мысли человека, которому иногда сложно" и "Как я начал учить Go и правда ли он похож на Python. Мой личный опыт".

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

Мысли по ходу прочтения первой статьи

Заранее оговорюсь, что с golang у меня почти нет реального опыта (один пет-проект, который я писал по видео на youtube и несколько дней с документацией), а на python я пишу уже более десяти лет, но все мысли автора, приведённые далее, исходят корнями к общему отсутствию базовых знаний, а не к знаниям в конкретных языках программирования.

Автор пишет:

Сначала я подумал, что это какая-то обёртка, типа как if __name__ == "__main__" в Python, но, похоже, нет. Тут без main вообще ничего не запускается. Это немного сбивает. Почему язык не может просто начать выполнять файл с первой строки?

Моя мысль: python интерпретируемый, а go - компилируемый язык. Потому он и не выполняется с первой строки. Это, если угодно, жанровая необходимость.

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

Удивление "странным типам" тоже ни к селу, ни к городу. Очевидно, что в python типизация неявная и динамическая, в то время как в golang она явная и статическая:

Я привык, что переменные сами понимают, кто они. В Python пишешь a = 5, потом a = "текст" — и всё нормально.

В Go, если ты сказал, что a int, то всё — никаких "текстов" туда не положишь. Я не сразу понял, как это работает. Ещё есть :=, и я не сразу понял, чем := отличается от =. Оказалось, := — это когда переменную создаёшь. А = — когда она уже есть. Почему нельзя просто одно оставить?

Форматируем вывод числа с учётом валюты и локали на фронтенде

#frontend #intl

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

const formatCurrency = (value, locale, currencyCode, config = {}) => {
    return new Intl.NumberFormat(locale, {
        style: "currency",
        currency: currencyCode,
        ...config,
    }).format(value)
}

console.log(formatCurrency(123456, "ru-RU", "RUB"))
// 123 456,00 р.

console.log(formatCurrency(123456, "en-US", "USD"))
// $123,456.00

Аргумент config был добавлен мною для возможности расширения текущей конфигурации экземпляра Intl, например, можно добавить параметр maximumSignificantDigits для округления до 3 значащих цифр:

console.log(formatCurrency(123456.789, 'ru-RU', 'RUB', { maximumSignificantDigits: 3 }))
// 123 000 р.

По-хорошему, бы тут добавить какую-то проверку, что аргументы передаваемые в config действительно находятся внутри Intl.NumberFormat и корректно им будут обработаны, а также защиту от перезаписывания заданных нами параметров, но моя цель была только в том, чтобы поделиться простым способом форматирования чисел с помощью встроенного браузерного API.

Если верить спецификации, коды валют берутся из стандарта ISO 4217. Мне не удалось найти оригинальный список кодов валют по этому стандарту не в PDF, но зато в онлайне есть наш ОКВ, который основан на этом стандарте.

Подробнее: https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat

Переключение сред исполнения в Vite

#советы #frontend #vite

Мало ли вы не знали, но в vite можно использовать MODE. При этом, он будет браться из имени вашего файла. К примеру, у вас есть .env.prod и .env.dev. Если вы хотите, чтобы какой-то код был доступен только в деве (например, когда вы только выкатываете новую фичу для теста, а ветка по какой-то причине одна, такое бывает), то вы можете использовать такой код для этого:

const isProdMode = import.meta.env.MODE === 'prod';

if (isProdMode) {
    // Код, который должен исполняться только в prod режиме
} else {
    // Код для других режимов
}

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

{isProdMode && <HelloWorld />}

При самой сборке и запуске можно указывать аргумент -m со значением dev или prod (или каким-либо другим значением, которое вы заложите).

  "scripts": {
    "start": "npm run dev",
    "dev:prod": "vite --port 3000 -m prod",
    "dev": "vite --port 3000 -m dev"
  }

Подробнее: https://vite.dev/guide/env-and-mode

Установка YAML-файла docker-compose по умолчанию

#советы #docker

Можно вот такой .env создать в корне проекта (или в том месте, где лежат композы, или в том месте, где вы обычно выполняете команду docker compose):

COMPOSE_FILE=docker-compose.dev.yml

Тогда команда docker compose будет по умолчанию брать тот файл, который таким образом указан и можно не писать docker compose -f docker-compose.dev.yml up, а ограничиться обычным docker compose up.

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

Сервис подборок с использованием NoORM / #1

#backend #бд

На прошлой неделе я писал пост про подход "не только ORM", в конце которого анонсировал публикацию нескольких постов по теме пет-проекта с использованием python-библиотеки true-noorm. Это первая часть, сегодня поговорим об организационных моментах, спроектируем сервис, поищем оптимальные решения, помучаем LLM и даже набросаем MVP.

В качестве проекта, на котором я хочу использовать NoORM был выбран сервис для формирования подборок из постов по интересующим темам.

Для начала хочется применить NoORM на этапе создания MVP. Критерии для того, чтобы можно было считать, что MVP реализовано:

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

По мере развития сервиса, хотелось бы реализовать следующие пункты:

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

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

🔍 Читать полную версию: https://blog.kantegory.me/podborka-1

👩‍💻 Github: https://github.com/kantegory/podborka

Что я прочитал - не только ORM

#чтояпрочитал #orm #бд

Ссылка на оригинал: https://habr.com/ru/articles/818761/
Ссылка на гитхаб проекта: https://github.com/amaslyaev/noorm

Кратко

В статье автор описывает устройство ORM и основную, на его взгляд, проблему такого подхода — "персистетные объекты". И предлагает альтернативу в виде кастомной библиотеки, позволяющей работать с БД без использования персистетных объектов, при этом не засоряя основной код SQL-запросами.

Выдержка про проблему персистентных объектов:

Примечательно здесь то, что работа с базой данных идёт через персистентные объекты, являющиеся экземплярами «модельных» классов, описывающих структуру БД. Эти персистентные объекты умеют себя прочитать из базы и в неё себя записать. Они живут внутри открытой сессии. И ещё эти объекты умеют «лениво» дотягивать из базы связанные с ними другие персистентные объекты. Эти самые персистентные объекты — корень всех проблем:

1. По сути, это передача мутабельного объекта в другой процесс. Безобразно тупая затея. Мы запросили сущность «пользователь Вася» из базы данных в процесс своего бэкенда, и теперь где у нас теперь мастер-копия? Как мы их собираемся синхронизировать, в какой момент, и что собираемся делать с возможными коллизиями?
2. Что случается с живущими в сессии объектами когда сессия закрывается? Что если они продолжают быть нужны в логике приложения? Что если эта логика продолжает считать, что это по-прежнему нормальные объекты, принадлежащие живой сессии?
3. Невозможно найти единственно правильный баланс между eager- и lazy-загрузкой. Если увлекаемся lazy, получаем проблему N+1, и всё начинает страшно тормозить. Если увлекаемся eager, на каждый невинный чих ORM пытается вычитать полбазы, и тоже всё тормозит. Короче, у нас две педали, но обе они педали тормоза.

Какой подход предлагает автор взамен?

Выделение отдельного модуля с логикой БД и SQL-запросами, который может выглядеть примерно так:

from dataclasses import dataclass
import noorm.sqlite3 as nm

@dataclass
class DbUser:
  id: int
  username: str
  email: str

@nm.sql_fetch_all(DbUser, "SELECT rowid AS id, username, email FROM users")
def get_users():
  pass

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

Выводы

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

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

Небольшой оффтоп по теме быта, ищу рекомендаций

Подумываю о покупке ультракороткофокусного проектора для домашнего просмотра фильмов и прочего видеоконтента. Знаю, что надо уделить внимание такому параметру, как яркость, чтобы можно было смотреть и не зашторивая комнату полностью. Примерно понимаю, какую диагональ хочу и чтобы было хотя бы FullHD, а лучше если 4K. Причём, интересует именно проектор.

Интересовался ли кто-то темой? Можете посоветовать, где можно посмотреть/почитать?

На ютубе обзоров крайне мало и в основном на бюджетные модели :(

Скрепка в vscode. Мнения?

Что я прочитал: "какие привычки освоить it-шнику, чтобы стать продуктивнее (или здоровее)?"

#чтояпрочитал #продуктивность

Ссылка на оригинал: https://habr.com/ru/articles/818923/

Кратко (полностью скопировано из самой статьи)

Общий список привычек на ежедневную основу

- Пространственные упражнения: особые упражнения для формирования настроя на день.
- Принятие холодного душа: холодный душ / обтирания / умывания для поднятия общего тонуса и настроя на день.
- Планирование следующего дня: планирование задач на следующий день в конце текущего.
- Чтение: чтение художественной / профессиональной литературы.
- Стакан воды с утра: выпивание стакана воды после пробуждения для увлажнения организма и стимуляции обмена веществ.
- Ходьба / Бег: регулярные прогулки или бег для поддержания физической формы и энергии.
- Сон по расписанию: соблюдение определенного режима сна, с учетом жизненных циклов организма и мира.
- Медитация: медитирование для улучшения концентрации, снятия стресса и общего благополучия.

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

На мой взгляд, точно будет работать:

- планирование следующего дня: я, к примеру, планирую все свои дела раз в неделю, а в конце дня просто сверяюсь с планом;
- чтение: меня пока что хватает только на ежедневное чтение разных статей и постов в тг, до книжек руки не доходят;
- стакан воды с утра: от воды в любом случае хуже не будет, а с утра действительно может помочь лучше проснуться;
- ходьба: именно ходьба, а не бег, потому что бег травмоопасен, а гулять на свежем воздухе — очень полезно;
- сон по расписанию: в ноябре прошлого года я уже писал про режим, рад поделиться тем, что уже более 3 недель удерживаю прекрасный режим без особых трудностей и делаю это довольно аккуратно. Мне помогают два будильника с интервалом 1.5 часа друг от друга. Первый за 1.5 часа до момента, когда мне надо проснуться, а второй ровно в то время, когда надо проснуться. Плюсом к этому, я включил сценарий светового будильника и когда я просыпаюсь с утра, чтобы выключить второй будильник, — в комнате уже светло, помогает легко встать.

Дополнительный пункт от меня: баланс между работой и жизнью (aka "work/life balance"). Я поставил себе чёткие рамки начала и окончания рабочего дня и это действительно помогает удерживаться от переработок и уменьшает энтропию.

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

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

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

Комментарии в коде

#дискуссия

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

Основной проблемой он считает то, что комментарии будут терять свою актуальность по мере внесения изменений в код.

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

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

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

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

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

А как вы подходите к написанию комментариев в коде?

Библия systemd — как управлять системой

Systemd — пожалуй, самая важная подсистема в Linux, без которой редко обходится развёртывание приложений на Linux-серверах.

Даже, если вы используете только контейнеризованные сервисы в docker, вам может пригодиться systemd для настройки автоматического перезапуска контейнеров после перезагрзузки.

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

[Unit]
Description=Echo server
After=multi-user.target
Conflicts=getty@tty1.service

[Service]
Type=simple
ExecStart=/usr/bin/python3 -m flask -A main.py run --host 0.0.0.0 --port 80
WorkingDirectory=/var/www/apps
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

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

https://habr.com/ru/articles/817701/

👩‍💻 Компонент для номера телефона (продолжение)

#frontend #react

Ресёрч пришлось продолжать. Я нашёл библиотеку, которая позволяла валидировать номер телефона относительно двухбуквенного кода страны, к которой этот номер относится. Кроме прочего, в этой библиотеке есть и возможность форматирования номера телефона, как раз под маску, принятую в конкретной стране. В описании библиотеки также упоминался react-компонент, который использует эту самую библиотеку. И на основе уже этого компонента, я собрал своё решение с использованием ant-design (разумеется, оно не идеальное, но достаточно хорошее, чтобы использовать в условном продакшне):

import PhoneInput from 'react-phone-number-input';
import PropTypes from 'prop-types';
import { getCountries } from 'react-phone-number-input';
import { Select as AntdSelect } from 'antd';

const phoneCountryLabels = () => {
    const countryLabels = {};

    getCountries().forEach((country) => (countryLabels[country] = country));

    return countryLabels;
};

const CountrySelect = ({ value, onChange, labels, variant = 'filled', ...rest }) => (
    <AntdSelect
        {...rest}
        value={value}
        showSearch
        optionFilterProp="label"
        onChange={onChange}
        variant={variant}
        size="large"
        style={{ '--ant-select-single-item-height-lg': '3rem' }}
    />
);

CountrySelect.propTypes = {
    value: PropTypes.string,
    onChange: PropTypes.func.isRequired,
    labels: PropTypes.objectOf(PropTypes.string).isRequired,
    variant: PropTypes.string,
};

const PhoneNumberInput = ({ onChange, country = 'US' }) => {
    return (
        <div className="base-phone-number">
            <PhoneInput
                onChange={onChange}
                defaultCountry={country}
                international
                limitMaxLength
                labels={phoneCountryLabels()}
                countrySelectComponent={CountrySelect}
                numberInputProps={{
                    className: 'ant-input ant-input-filled css-var-r1 ant-input-css-var base-input',
                }}
            />
        </div>
    );
};

PhoneNumberInput.propTypes = {
    onChange: PropTypes.func.isRequired,
    country: PropTypes.string,
};

export default PhoneNumberInput;

А как вы решали подобные задачи? Делитесь, будет интересно узнать.

P. S. как появится немного времени, планирую тоже самое адаптировать под vue-компонент и поделиться результатом

👩‍💻 Компонент для номера телефона

#frontend #react

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

Пару недель назад я как раз столкнулся с подобной задачей в рамках проекта на react и захотел попробовать реализовать это с помощью imask, но столкнулся с проблемой: нужно отображать список стран, с привязанным к ним кодом. В imask есть возможность решить это, но нет готового набора кодов номеров телефонов. Я вспомнил о решении, которое мои сотрудники находили. Попробовал его адаптировать и понял, что я особо не могу его кастомизировать (по дизайну требовалось выводить двухбуквенное название страны, а не флаг), несмотря на его описание, — "Advanced, highly customizable phone input component for Ant Design."

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

Пример с самого сайта imask, где наглядно видно, что маски вообще не подчиняются единым правилам и могут выглядеть абсолютно как угодно:

[
    {
      mask: '+00 {21} 0 000 0000',
      startsWith: '30',
      lazy: false,
      country: 'Greece'
    },
    {
      mask: '+0 000 000-00-00',
      startsWith: '7',
      lazy: false,
      country: 'Russia'
    },
    {
      mask: '+00-0000-000000',
      startsWith: '91',
      lazy: false,
      country: 'India'
    },
    {
      mask: '0000000000000',
      startsWith: '',
      country: 'unknown'
    }
]

👩‍💻 Что нужно знать python backend developer для устройства на работу

#django #python #backend #fastapi

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

👩‍💻 Фреймворки:

- Django (+ DRF),
- FastAPI/Flask (+ alembic, sqlalchemy).

👩‍💻 Базы данных:

- redis,
- postgresql.

👩‍💻 Основы:

- HTTP-протокол, HTTP-методы,
- что такое REST, REST API, RESTful,
- что такое CORS и как его победить,
- linux/unix на уровне понимания работы по SSH, права доступа,
- понимание концепции MVC и принципа работы паттерна репозиторий (больше нужен для работы с SQLAlchemy),
- вопросы для подготовки к интервью (список там довольно большой, обращайте внимание на те моменты, по которым вы совсем ничего не знаете).

👩‍💻 Что нужно знать в django:

Обязательно:

- работа с django ORM: https://docs.djangoproject.com/en/5.0/topics/db/queries/,
- миграции в django ORM: https://docs.djangoproject.com/en/5.0/topics/migrations/,
- менеджеры моделей: https://docs.djangoproject.com/en/5.0/topics/db/managers/,
- сериализаторы, представления и права доступа из DRF: https://www.django-rest-framework.org/tutorial/quickstart/,
- работа с фильтрами через django-filter: https://django-filter.readthedocs.io/en/stable/guide/usage.html.

Опционально:

- формы: https://docs.djangoproject.com/en/5.0/ref/forms/,
- admin actions: https://docs.djangoproject.com/en/5.0/ref/contrib/admin/actions/,
- оптимизация запросов в Django ORM: https://t.me/davidobryakov/1195,
- отправка почтовых уведомлений: https://docs.djangoproject.com/en/5.0/topics/email/.

На уровне концепции:

- работа с админкой: https://docs.djangoproject.com/en/5.0/ref/contrib/admin/,
- сигналы: https://docs.djangoproject.com/en/5.0/topics/signals/.

Полезные библиотеки и ссылки для django:

- библиотека для установки настроек CORS: https://github.com/adamchainz/django-cors-headers,
- библиотека для авторизации и регистрации через DRF: https://djoser.readthedocs.io/en/latest/,
- библиотека для создания динамической конфигурации приложения, хранимой в БД: https://django-constance.readthedocs.io/en/latest/,
- библиотека, добавляющая хуки жизненного цикла для моделей Django: https://rsinger86.github.io/django-lifecycle/,
- библиотека, предоставляющая кастомную админку с большим количеством настроек: https://django-jazzmin.readthedocs.io/,
- практические советы для начинающих Django-разработчиков: https://t.me/davidobryakov/1184,
- подборка лучших библиотек для Django: https://t.me/davidobryakov/1139,
- курс по Django на MDN: https://developer.mozilla.org/ru/docs/Learn/Server-side/Django,
- мой шаблон для Django-проектов: https://github.com/kantegory/django-template.
- работа с ORM SQLAlchemy: https://docs.sqlalchemy.org/en/20/intro.html,
- работа с alembic: https://alembic.sqlalchemy.org/en/latest/,
- понимание async/await: https://docs.python.org/3/library/asyncio-task.html.

👩‍💻 Что нужно знать/уметь в FastAPI/Flask:

- не поместилось по лимиту в ТГ, читайте полную версию поста в блоге.

Общие требования:

- работа с очередями задач с помощью Celery + Redis/Celery + RabbitMQ (выполнение периодических или отложенных задач, например, отправка электронной почты);
- настройка общения между сервисами посредством RabbitMQ

👩‍💻 Инструменты:

- git (тренажёр: https://learngitbranching.js.org/?locale=ru_RU),
- docker, docker compose (на уровне: могу прочесть конфиг, могу запустить проект, могу написать свой простой конфиг),
- gunicorn/uvicorn (иметь представление о том что это и для чего используется),
- nginx (понимание на уровне директив location и upstream).