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

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

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

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

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

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

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

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

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

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

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

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

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

Старый-добрый swagger-jsdoc

Крайне простое в использовании решение, которое требует от вас только терпения и времени. По сути, вы описываете все эндпоинты через специальные jsdoc-комментарии, по формату совпадающие с OpenAPI в YAML.

Библиотека же ходит по вашему коду, собирает все такие комментарии и встраивает их в общий файлик OpenAPI.

Пример кода:

/**
 * @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)

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

Плюсы и минусы

Плюсы:

• простота
• универсальность

Минусы:

• много ручной работы

Полный код примера

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

Пишем как на Nest: routing-controllers

Если вы начинаете с express, но планируете перейти на Nest позднее, то routing-controllers - ваш выбор. Синтаксически это почти один-в-один совпадает с Nest.

Пример кода:

@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);
    }
}

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

Типы для документации собираются на основе class-validator, как и в Nest. Что фактические вынуждает вас к валидации входящих данных.

Стоит отметить, что само по себе, решение не предоставляет возможностей для генерации документации, это делается за счёт использования библиотеки routing-controllers-openapi. У неё есть проблема, из-за которой могут быть проблемы с работой рантайма tsx. Не могу сказать, что я как-то сильно погружался, но по моим ощущениям, это связано с некорректной обработкой данных из метадаты. К счастью, это исправляется либо за счёт monkey-патча, либо за счёт использования моего форка.

У меня есть даже свой бойлерплейт на основе routing-controllers. Правда, он не до конца написан, но начало положено...

Плюсы и минусы

Плюсы:

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

Минусы:

• проблема с рантаймом tsx
• остаётся ли express всё ещё таким же лёгким?

Полный код примера

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

Ещё немножко декораторов: tsoa

Да, снова декораторы. Но tsoa - решение куда более комплексное, чем routing-controllers. По крайней мере, на мой взгляд.

Давайте посмотрим на пример:

@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,
        };
    }
}

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

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

Для меня tsoa - самое оптимальное решение. Буду во все новые проекты на Node брать именно эту библиотеку.

Плюсы и минусы

Плюсы:

• код более структурирован
• встроенная валидация
• единое решение для контроллеров и автодокументирования
• синтаксически близко к Nest

Минусы:

• остаётся ли express всё ещё таким лёгким?

Полный код примера

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

Выводы

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

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

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

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

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

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

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

Автор пишет:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

• Введение
• Выбор технологий
• Проектирование БД
• Парсинг хабра
• Создание БД
• NoORM
• Точка входа
• Заключение

Введение

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

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

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

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

Общая архитектура для MVP (с учётом возможностей расширения):

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

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

Выбор технологий

Если по основным технологиям всё было понятно, то вот что делать с RSS — мыслей не было никаких, я никогда ранее не работал с RSS самостоятельно, пара минут в гугле привели меня к библиотеке feedparser.

В качестве технологий я хочу использовать:

• FastAPI,
• NoORM,
• feedparser,
• vue.js + antd + pinia (для визуализации подборки),
• postgresql,
• docker,
• nginx.

На клиентскую часть решил взять vue + antd, чтобы попрактиковаться в использовании antd в рамках vue (ранее пробовал его только с react).

Проектирование БД

Для рисования диаграмм БД я использую drawio. Я не преследую целей соблюдать нотацию на все сто процентов, мне нужна только наглядность и отношение сущностей между собой.

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

Парсинг хабра

В целом, на самом хабре прекрасно описано, что надо сделать, чтобы получить доступ к RSS. Из всех возможных RSS-лент на хабре, лично мне пока хватит двух лент:

• лучшие публикации сайта;
• все публикации сайта подряд.

В итоге за примерно 30-35 минут накидал следующий файлик (rss.py) с кодом для парсинга RSS с хабра:

import feedparser
from dataclasses import dataclass

habr_all_publications = 'https://habr.com/ru/rss/articles/?fl=ru'
habr_best_publications = 'https://habr.com/ru/rss/articles/top/daily/?fl=ru'


@dataclass
class Post:
    title: str
    description: str
    meta_info: dict[str, any]


def parse(link):
    feed = feedparser.parse(link)

    posts = []

    for post in feed.entries:
        posts.append(
            Post(
                title=post.title,
                description=post.summary,
                meta_info={
                    'published_at': post.published,
                    'author': post.author,
                    'tags': list(map(lambda tag: tag['term'], post.tags)),
                    'link': post.link,
                }
            )
        )

    return posts


def generate_feed(sources):
    posts = []

    for source in sources:
        posts_by_source = parse(source)

        posts.extend(posts_by_source)

    return posts

sources = [habr_all_publications, habr_best_publications]

results = generate_feed(sources)

print('Length of posts:', len(results))

Функция parse выкачивает RSS-ленту по ссылке, собирает коллекцию постов и возвращает её. Функция generate_feed проходит по всем ссылкам, полученным на вход, формирует коллекцию публикаций, обращаясь к функции parse.

Создание БД

Поскольку, подход NoORM не предусматривает автоматического создания БД и заполнения БД, необходимо собрать SQL-скрипт для инициализации БД.

Я довольно ленивый, когда дело доходит до SQL, поэтому скормил в LLM такой промпт:

"Напиши sql запрос для создания таблицы dt_user со следующими полями: id (первичный ключ), login, password, таблицы dt_feed со следующими полями: id (первичный ключ), name, created_at, foreign key на таблицу dt_user, таблицы dt_source с полями id (первичный ключ), name, link, type, таблицы dt_post со следующими полями: id (первичный ключ), title, description, meta_info, raw_content, mark, created_at, foreign key на таблицу dt_feed, foreign key на таблицу dt_source"

На выходе получил такой результат:

CREATE TABLE dt_user (
    id INT AUTO_INCREMENT PRIMARY KEY,
    login VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL
);

CREATE TABLE dt_feed (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    user_id INT,
    FOREIGN KEY (user_id) REFERENCES dt_user(id)
);

CREATE TABLE dt_source (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    link VARCHAR(255) NOT NULL,
    type ENUM('RSS', 'ATOM') NOT NULL
);

CREATE TABLE dt_post (
    id INT AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    meta_info JSON, -- если используется MySQL версии 5.7 и выше
    raw_content TEXT,
    mark BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    feed_id INT,
    source_id INT,
    FOREIGN KEY (feed_id) REFERENCES dt_feed(id),
    FOREIGN KEY (source_id) REFERENCES dt_source(id)
);

В целом, довольно неплохо, но мне надо для psql, поэтому решил перезапросить с уточнением:

"Напиши sql запрос с использованием СУБД postgresql для создания таблицы dt_user со следующими полями: id (первичный ключ), login, password, таблицы dt_feed со следующими полями: id (первичный ключ), name, created_at, foreign key на таблицу dt_user, таблицы dt_source с полями id (первичный ключ), name, link, type, таблицы dt_post со следующими полями: id (первичный ключ), title, description, meta_info, raw_content, mark, created_at, foreign key на таблицу dt_feed, foreign key на таблицу dt_source"

CREATE TABLE dt_user (
    id SERIAL PRIMARY KEY,
    login VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL
);

CREATE TABLE dt_feed (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    user_id INTEGER REFERENCES dt_user(id) ON DELETE CASCADE
);

CREATE TABLE dt_source (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    link VARCHAR(255) NOT NULL,
    type VARCHAR(10) NOT NULL CHECK (type = 'RSS' OR type = 'ATOM')
);

CREATE TABLE dt_post (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    meta_info JSONB, -- JSONB поддерживает индексацию и поиск
    raw_content TEXT,
    mark BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    feed_id INTEGER REFERENCES dt_feed(id) ON DELETE CASCADE,
    source_id INTEGER REFERENCES dt_source(id) ON DELETE RESTRICT
);

Как видно, скрипт вполне неплохой получился. От себя, я добавил только IF NOT EXISTS к созданию каждой таблицы. А по названию полей LLM попыталась расставить типы и вполне неплохо с этим справилась. Интересно, что здесь даже предусмотрено сразу ограничение типов источника, что пока не слишком актуально, но в целом, — очень даже неплохо. Подытоживая, такого скрипта мне более, чем достаточно для MVP.

Теперь, когда скрипт init.sql готов, осталось только накидать простенький docker-compose.yml, чтобы запустить БД:

services:
    db:
        image: postgres
        container_name: podborka_db
        environment:
            - POSTGRES_DB=maindb
            - POSTGRES_USER=maindb
            - POSTGRES_PASSWORD=maindb
            - POSTGRES_HOST=db
            - POSTGRES_PORT=5432

        ports:
            - 15432:5432

        volumes:
            - ./dbs/postgres-data:/var/lib/postgresql/data
            - ./init.sql:/docker-entrypoint-initdb.d/init.sql

Проверим, что всё создалось, зайдя в БД:

maindb=# \dt;
          List of relations
 Schema |   Name    | Type  | Owner  
--------+-----------+-------+--------
 public | dt_feed   | table | maindb
 public | dt_post   | table | maindb
 public | dt_source | table | maindb
 public | dt_user   | table | maindb
(4 rows)

Как видим, всё на месте. Можно переходить к настройке работы через NoORM.

NoORM

Чтобы использовать NoORM вместе с PostgreSQL, надо установить адаптор. В данный момент, я остановился на библиотеке psycopg2. В будущем планирую перейти на asyncpg, но для MVP в этом никакой необходимости нет.

Установим зависимости (я использую именно binary-версию для psycopg2):

pip3 install true-noorm psycopg2-binary

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

from dataclasses import dataclass

import noorm.psycopg2 as nm


@dataclass
class DbUser:
    id: int
    login: str

@nm.sql_fetch_all(DbUser, "SELECT id, login FROM dt_user")
def get_all_users():
    ...

@nm.sql_one_or_none(
    DbUser, "SELECT id, login FROM dt_user id = :id"
)
def get_user_by_id(id: int):
    return nm.params(id=id)

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

Реализуем функцию для создания нового пользователя через INSERT-запрос (опять же, посредством допроса LLMки):

@nm.sql_execute("INSERT INTO dt_user (login, password) VALUES (%s, %s)")
def create_new_user(login: str, password: str):
    return nm.params(login, password)


def main():
    import psycopg2

    with psycopg2.connect(
     database='maindb', user='maindb',
     password='maindb', host='localhost',
     port='15432'
 ) as conn:
        create_new_user(conn, 'test', 'test')
        conn.commit()

main()

Синтаксис корректного запроса (имею ввиду, что в данном случае параметры не именованные и это неочевидный момент) я подглядел в примерах, которые лежали внутри кода библиотеки. И первое, что меня расстроило в работе с NoORM: в результате выполнения запроса я не получил никакой информации о только что созданной записи, только None. А всё-таки, хотелось бы получить, хотя бы, id. С другой стороны, этим автор библиотеки неявно подталкивает нас к тому, чтобы делать в такой ситуации два запроса и сохранять при этом простоту взаимодействия.

Опишем такие же круды для остальных таблиц. Полный код проекта можно посмотреть на моём github.

Точка входа

Теперь, когда мы уже написали все функции для работы с БД, а также простой инструмент для парсинга RSS-лент, нам следует подружить две эти части нашего приложения между собой. Для этого я немного модифицировал файл rss.py:

import feedparser
from dataclasses import dataclass, asdict

import psycopg2
import json

from db.posts import create_new_post


@dataclass
class Post:
    title: str
    description: str
    meta_info: dict[str, any]


def parse(link):
    feed = feedparser.parse(link)

    posts = []

    for post in feed.entries:
        posts.append(
            Post(
                title=post.title,
                description=post.summary,
                meta_info={
                    'published_at': post.published,
                    'author': post.author,
                    'tags': list(map(lambda tag: tag['term'], post.tags)),
                    'link': post.link,
                    # TODO: добавить поля
                    # 'raw_content': '-',
                    # 'mark': '-',
                    # 'feed_id': 1,
                    # 'source_id': 1,
                }
            )
        )

    return posts


def generate_feed(sources):
    posts = []

    for source in sources:
        posts_by_source = parse(source)

        posts.extend(posts_by_source)

    return posts


def save_posts(posts):
    with psycopg2.connect(database='maindb', user='maindb', password='maindb', host='localhost', port='15432') as conn:
        for post in posts:
            create_new_post(conn, **{ **asdict(post), 'meta_info': json.dumps(post.meta_info) })

        conn.commit()


def load_posts(sources):
    results = generate_feed(sources)

    print('First result:', results[0])

    print('Length of posts:', len(results))

    save_posts(results)

По сути, мы дописали две функции: save_posts для записи результатов парсинга в БД и load_posts для объединения процессов генерации нашей подборки с последующим сохранением в БД.

Настало время реализовать точку входа, которая в будущем перейдёт под FastAPI, файл main.py:

from parser.rss import load_posts

habr_all_publications = 'https://habr.com/ru/rss/articles/?fl=ru'
habr_best_publications = 'https://habr.com/ru/rss/articles/top/daily/?fl=ru'

sources = [habr_all_publications, habr_best_publications]

load_posts(sources)

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

$ python3 main.py 
Rirst result: Post(title='Team Lead VS Engineering Manager', description='<img src="https://habrastorage.org/getpro/habr/upload_files/800/cdc/5f1/800cdc5f15df57e3ef7d1ff7d736a6ed.jpeg" /><p>Приветствую! Меня зовут Василиса Версус и я в прошлом трижды СТО в небольших стартапах (20-50 чел), а также head of инфраструктуры / разработки в таких компаниях как Яндекс и Сбермаркет</p><p>Сегодня мне очень хочется поделиться несколькими мыслями на тему карьерного развития. И недостающими пазлами между позицией тимлида и желаемой многими позиции СтанцииТехническогоОбслуживания.</p> <a href="https://habr.com/ru/articles/827094/?utm_source=habrahabr&amp;utm_medium=rss&amp;utm_campaign=827094#habracut">Читать далее</a>', meta_info={'published_at': 'Sat, 06 Jul 2024 15:16:46 GMT', 'author': 'dcversus', 'tags': ['engineering management', 'team leading', 'development', 'career advice', 'cto', 'тимлидство'], 'link': 'https://habr.com/ru/articles/827094/?utm_source=habrahabr&utm_medium=rss&utm_campaign=827094'})
Length of posts: 61

На всякий случай, проверим это и запросом в БД:

maindb=# select count(*) from dt_post;
 count 
-------
    61
(1 row)

Заключение

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

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

Ссылка на оригинал: 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. В ближайшие дни будет несколько постов по этой теме. Подумываю о том, чтобы снять об этом даже полноценное видео (не о самом подходе, а скорее о пет-проекте).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Около месяца назад я писал пост про библиотеку 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'
    }
]

Ресёрч пришлось продолжать. Я нашёл библиотеку, которая позволяла валидировать номер телефона относительно двухбуквенного кода страны, к которой этот номер относится. Кроме прочего, в этой библиотеке есть и возможность форматирования номера телефона, как раз под маску, принятую в конкретной стране. В описании библиотеки также упоминался 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-компонент и поделиться результатом

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

Фреймворки

• 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/ (на уровне концепции)

Будет плюсом

• важная проблема с админкой, о которой стоит знать: https://stackoverflow.com/questions/16755312/django-admin-change-form-load-quite-slow

Полезные библиотеки и ссылки для 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.

Что нужно знать/уметь в FastAPI/Flask

Обязательно

• работа с 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.

Опционально

• работа с TortoiseORM: https://tortoise.github.io/index.html.

Полезные ссылки по FastAPI/Flask

• библиотека для работы с пользователями, авторизацией и регистрацией: https://fastapi-users.github.io/fastapi-users/latest/,
• админка, работающая с TortoiseORM: https://github.com/fastapi-admin/fastapi-admin,
• админка, работающая с SQLAlchemy: https://github.com/aminalaee/sqladmin,
• библиотека, упрощающая взаимодействие с SQLAlchemy: https://github.com/e-kondr01/fastapi-sqlalchemy-toolkit.

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

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

Инструменты

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

Пару лет назад я писал про WebVM, который представляет из себя linux без графической оболочки, работающий через WASM. Пару недель назад видел несколько постов про InternetOS puter. По сути, она представляет из себя графическую оболочку рабочего стола, работающую на веб-технологиях (js + jQuery).

В отличие от WebVM, puter это только GUI, операции происходят на сервере (заметно, что на каждое действие, отправляется запрос в API). Документации для API-сервера пока что нет. Его исходного кода мне также не удалось найти (допускаю, что плохо искал, хотя и заглянул в каждый репозиторий). Разработчики обещают опубликовать документацию по API-серверу к концу марта, чего я буду ждать с нетерпением.

Как вы думаете, есть ли будущее у браузерных операционных систем? Смогут ли они со временем стать заменой привычным десктопным оболочкам?

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