Дима пишет | Дмитрий Смотров

Пробился на хабр

Tue, 02 Dec 2025 19:23:53 +0300

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

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

Почитать можно тут — https://habr.com/ru/companies/astralinux/articles/972328/ . Там как раз есть пара спорных моментов, на мой взгляд, с удовольствием подхвачу накидывание на вентилятор. Так что задавайте ваши вопросы :)

Там новая версия питона вышла, пошли посмотрим

Mon, 20 Oct 2025 23:24:47 +0300

Почти две недели назад вышла новая версия питончика — 3.14. Хочу осмотреться и выписать интересные изменения в сравнении с версией 3.13. Вообще давно хотел пробежаться по ченжлогу с версии 3.7, которая долго была в строю в качестве основной версии во многих компаниях(и наверняка где-то еще используется, мы вот в начале этого года перешли на 3.11), до текущих свежих версий.

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

Из интересного

Официально можно вырубить GIL. Ребята перешли на вторую фазу проекта по отказу от GIL, в которой можно собрать CPython с флагом —disable-gil. До этого такие билды были эксперементальными, третьим этапом планируется по умолчанию быть дружелюбными к потокам.
Выкатили эксперементальные сборки интерпретатора с JIT. Бинарники доступны для винды и маков, линуксоиды могли использовать и до сего момента.. В прод крайне не рекомендуют заносить, так как вместо увеличения производительности вы можете поймать наоборот словить даунгред. Сейчас получают как 20% прироста, так и 10% снижения производительности на тестах.

Из полезного

Добавили новый тип строки template strings(t-строки) для шаблонизации. Такая строка разбивается на статические и «подставляемые» составляющие(те самые фигурные скобки из f-строк), для которых ввели специальный тип Interpolation, а сами t-строки имеют тип Template. Прикольное.
Маленький пример:

from string.templatelib import Interpolation

def lower_upper(template):
    """Render static parts lowercase and interpolations uppercase."""
    parts = []
    for part in template:
        if isinstance(part, Interpolation):
            parts.append(str(part.value).upper())
        else:
            parts.append(part.lower())
    return ''.join(parts)

name = 'Wenslydale'
template = t'Mister {name}'
assert lower_upper(template) == 'mister WENSLYDALE'

Добавили cli-команду для просмотра запущенных асинхронных тасок. Вывод похож на вывод команды ps, можно запросить древовидный вид. Однозначно приятное.
Завезли UUID с 6 по 8 версии в модуль uuid, импрувнули скорость генерации для версии с 3 по 5.
Теперь интерпретатор более дружелюбно подсказывает, где и как вы накосячили в коде, если находит синтаксическую ошибку.
В копилку к дружелюбности: сейчас добавили ворнинги при использовании return/break/continue в блоке finally. В будущем планируют падать с ошибкой.

Из забавного

Теперь группу отлавливаемых исключений в except и в except*(введен в версии 3.11, расскажу о нем в будущем) блоках можно писать без скобочек:

# Было
try:
    connect_to_server()
except (TimeoutError, ConnectionRefusedError):
    print('The network has ceased to be!')

# Стало
try:
    connect_to_server()
except TimeoutError, ConnectionRefusedError:
    print('The network has ceased to be!')

Лично меня скобочки не смущали, не совсем понял прикола, ну да ладно.

Интерактивный интерпретатор теперь поддерживает цвета! Когда открывали его в последний раз? Признавайтесь.
Консольный отладчик теперь можно удаленно натравить на работающий процесс. Им все же кто-то пользуется :)

Минимально необходимая автоматизация

Sun, 28 Sep 2025 14:20:29 +0300

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

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

Это работает как для одного файла, так и для группы файлов, если в купе они образуют совокупность семантических единиц. Например вы разом создаете часть сервисного слоя, часть слоя работы с БД, а так же создаете обработчики HTTP запросов на базовые CRUD операции, если API методы реализуются с нуля.

На гифке для примере создается реакт компонент, для простоты искал пример для vscode.

В целом можно взять любой движок шаблонов, разницы нет, главное, чтобы файлы-шаблоны добавлять было удобно, а использовать через cli интерфейс в консоли, если нет возможности вызывать из интерфейса вашей IDE. Можно обойтись сниппетами, так же добавив нужные аббревиатуры и правила заполнения содержимого, но файловую структуру придется забивать самостоятельно. Даже так это ускорит вашу разработку.

Если у вас руки совсем развязаны, то тренеруйте llm’ку, пусть за вас все делает :)

12 факторов. Часть 4

Sun, 14 Sep 2025 22:57:25 +0300

10) Паритет разработки/работы приложения. Держим среду разработки идентичной среде развертывания. Если на проде используется Postgres, то локально мы тоже используем Postgres, никаких SQLite/Oracle/MySQL, иначе вы очень рискуете стать тем самым «а у меня локально все работает» парнем. На моей практике различие версии одной зависимости между стейджем и продом привели к двухнедельному кранчу. Фактор обеспечивает способность непрерывного развертывания приложения за счет минимизации различий между средами разработки и исполнения.
11) Журналирование. Логи как поток событий. Приложение отдает контроль за своими логами на аутсорс стороннему инструментарию(привет ELK, а если точнее, то logstash). Каждый процесс пишет логи в стандартный вывод, а там оно уже как-нибудь «само». Почему? Опять же: для простоты масштабирования. Еще важно подчеркнуть — логи рассматриваются как поток событий(одна строка логов — одно событие системы), из которых формируется журнал. Журнал — это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. По сути это такой же текстовый файл, но его можно визуализировать для удобства(привет Kibana).
12) Администрирование. Выполняем администрирование в разовых процессах, причем среда выполнения таких процессов идентична среде выполнения всего приложения. К администрированию относится выполнение миграций, запуск разовых скриптов(например пользака с админскими правами создать), и тому подобное. Очень сильно перекликается с 10 пунктом и нужно по тем же причинам: если мы будем запускать приложение в одной среде, а администрировать приложение в другой, мы точно в конечном итоге нарвемся на рассогласование конфигураций. Хранить разовые скрипты рекомендуется рядом с основным кодом приложения.

12 факторов. Часть 3

Thu, 04 Sep 2025 16:42:49 +0300

7) Привязки портов. Сервисы экспортируются через бинд порта — то есть сервис тусит на порту и слушает запросы. Тут камень в огород способа развертывания приложения как дополнительного модуля к веб серверу, существовавшему ранее. Сейчас же будьте добры делать приложение самодостаточным, идущем в комплекте с собственным веб-сервером(который вы объявите в зависимостях), а не подсовывайте сервер извне.
8) Параллельное выполнение команд. И для параллельного выполнения используются процессы. За основу взяли все хорошее из модели Unix процессов + разделение на типы процессов: если сервис будет обрабатывать HTTP-запросы и выполнять задачи в фоне, то сервис должен быть разделен на веб-процесс и процесс фоновых задач. Таким образом, если увеличивается нагрузка на веб-процесс, то мы докидываем дополнительный веб процесс. Аналогично для процесса фоновых задач. На картинке можно наглядно посмотреть. Вот тут пост сооснователя heroku с предложением данной концепции.
9) Утилизируемость. Приложение должно запускаться и останавливать свою работу в любой момент, когда это потребуется. В идеале мы минимизируем время запуска, а процесс завершения делаем безопасным — завершаем текущую сессию с БД, чтобы соединения не текли, завершаем все фоновые задачи, только после этого процесс умирает. Хорошо бы еще добавить устойчивость к внезапной смерти оборудования, но подобное событие считается менее вероятным, чем простое завершение работы по SIGTERM. Весь этот фактор направлен на то, чтобы автомасштабирование работало по принципу «включил/выключил», как свет на кухне: нужно — добавили подов, ненужно — убрали.

12 факторов. Часть 2

Wed, 06 Aug 2025 09:49:43 +0300

Прошлый пост

4) Сторонние службы. Это службы, доступные приложению по сети. База данных, очереди сообщений, кеши — все это сторонние службы и они должны быть *подключаемыми ресурсами*, доступными по URL-адресу, который в свою очередь заносится через параметры конфигурации. В случае, если сервер сторонней службы начинает барахлить, служба переносится на другой сервер и приложению дают URL с новым сервером.
5) Сборка, релиз и выполнение. Жесткое разделение этапов развертывания приложения на сборку(берем код и «компилируем» его: ставим зависимости в окружение; реально компилируем, если ЯП проекта компилируемый), релиз(к «собранной» программе докидываются конфиги) и выполнение(непосредственно запуск программы) позволяет контролировать то, какой код был развернут на сервере с помощью систем контроля релиза(например Jenkins), которые в случае чего позволят откатить релиз и проанализировать проблемный релиз на предмет ошибок.
6) Процессы. Приложение запускается как один, либо как несколько процессов, без сохранения внутреннего состояния(сервис без состояния — *stateless*). Так же между процессами не должно быть разделяемых данных. Это нужно для упрощения горизонтального масштабирования — просто добавь ~~воды~~ еще один процесс. В случае, если у сервиса есть состояние(допустим, он кеш хранит в глобальном словаре), то нужно это состояние распространить и держать согласованным между всеми инстансами приложения. Состояние, если оно у вас есть, должно быть вынесено во внешнюю службу(для нашего примера для кеша использовать Redis/Memcached).

12 факторов. Часть 1

Sun, 03 Aug 2025 21:25:44 +0300

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

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

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

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

1) Кодовая база. Одна кодовая база — одно приложение. Кодовая база ведется с помощью системы контроля версий, любой, на ваш вкус. Каждый разработчик в команде работает с одним и тем же кодом(изменения, внесенные разработчиком во время работы не противоречат этому пункту), на серверах запускается этот же код. Представьте, что у вас есть N друзей близняшек, одевающихся почти одинаково. Отличать их друг от друга смогут разве что родители(а смогут ли?).
2) Зависимости. Приложения явно указывает пакеты, которые нужны ему для работы через манифесты декларации зависимостей и менеджер зависимостей. Таким образом мы избегаем ситуаций, когда в одной среде приложение работает корректно, а при запуске на другом компьютере приложение падает из-за отсутствия нужной библиотеки.
3) Конфигурация. Должна подкидываться приложению из переменных окружения. Если вы прибьете гвоздями креды для подключения к БД в коде, а потом поменяете пароль на сервере базы или же переместите базу на другой хост, то без патча в исходном коде приложения вы банально не заведетесь.

В последующих постах пройдемся и по остальным 9 пунктам :)

Профессионал приходит со своими инструментами

Wed, 23 Jul 2025 11:31:32 +0300

Люблю задавать вопрос «Какой ваш любимый набор инструментов для разработки?». Чаще всего в ответ слышу «Такого нет/Не знаю, на чем скажут, на том и сижу».

Для меня такой ответ непонятен: вы кучу времени за работой, прям вообще ни одного инструмента, без которого вам работать менее приятно, за столько времени вы не нашли? Да, хоткеи много где совпадают, но чтобы делать работу лучше и быстрее, важно, чтобы вы знали свой инструмент, чтобы он был «заточен».

Много разрабов, кто делал что-то прикольное, имеет заточенный для себя набор утилит от редактора до менеджера окон. Хорошей практикой я нахожу создание папки с конфигами и закидывания ее в git. Я таким образом перепрыгивал на разные рабочие места(или на разные ОС) и всегда под рукой было все, что нужно для работы. Можно еще автоматизировать установку через разные скрипты, но тут я поленился :)

Для меня список следующий, начнем с консольных инструментов:
— консоль с установленным fish-shell. Я долго просидел на дефолтной убунтовской, но обратно возвращаться не хочу. К fish’у я добавил менеджер плагинов и пару плагинов: для работы с git и fzf, он же fuzzy-search. Первый позволяет написать короткую мнемонику команды вместо полной, например gcm — это git commit -m. Последний добавляет комбинации клавиш для поиска по файлам, истории команд, запущенным процессам, логу гита, переменным окружения.
— rg(ripgrep, улучшенный grep), bat(улучшенный cat). Нужны для вима, но использую их вместо прородителей. Их cli интерфейс мне нравится больше, да и bat сразу с подсветкой синтаксиса.
— httpie — замена для curl, с более удобным cli интерфейсом(для curl запарно запоминать набор параметров) и хорошей документацией.
— hyperfine — тулза для бенчмарков. С ее помощью первично прозваниваю ендпоинты на нагрузку.
— tmux с плагинами на сохранение сессий, поиск по имени сессии и кастомизации внешнего вида. В нескольких сессиях открыты разные проекты.
— nvim, куда без него. Использую LazyVim, подпиленный напильником.

Из не консольного:
— Pycharm, в основном для разруливания конфликтов или копирования папок между проектами, тут это удобно делать.
— DataGrip. Ничего лучше для работы с БД еще не находил. В чарме тоже есть вкладка с подключениями в БД, тут по сути эта вкладка вынесена в отдельный продукт от JB и мне так удобнее.
— Nimble Commander. Это тот же Midnight Commander, только для мака.

Готовьте свою рабочую среду для себя, так реальнее кайфовее работать.

Неявные последствия выбора архитектуры

Fri, 11 Jul 2025 11:19:58 +0300

Фото специально размыто, коммерческая тайна и все такое :)

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

Наши сервисы имеют слоистую архитектуру с кучей другой паттернов: адаптеры, репозитории для запросов в хранилище, команды и запросы(привет CQRS), unit of work для обеспечения транзакционности действий в системе, агрегаты, сервисы, билдеры на сервисы и билдеры на модели, все еще на интерфейсах, чтобы тестировать удобно было... Чтобы реализовать ручку, нужно реализовать 5-6 интерфейсов и реализаций. Ситуация, как в тех бородатых анекдотах про реализацию чего-угодно в Java: сначала напишите фабрику, а если фабрика уже есть — напишите абстрактную фабрику. Пришлось вспоминать, как вообще все эти сущности между собой должны дружить.

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

Отсюда два вывода:
1) Настраивайте себе шаблонизаторы, когда у вас устоявшиеся подходы.
2) Если ваш сервис предполагает, что про его разработку забудут на полгода-год(на моей памяти есть такой сервис для получения курса валют), есть смысл писать его проще — в плоских структурах и куче if-ов быстрее разобраться(да-да, рубрика «Вредные советы»). Опять же если не написана совсем жесть, тогда земля пухом 🔫.

💻 Всем доброй ночи, а я пошел запиливать себе шаблоны наконец-то, ибо те 30 файликов на скрине ПРа меня утомили. Это кстати реализация Create операции, с тестами...

Похождения Redis’a

Fri, 11 Jul 2025 11:12:52 +0300

Год назад Redis решил сменить лицензию в рамках своей войны с облачными провайдерами, которые предоставляют managed service. Мол «не хорошо, что ребята пользуются плодами open source, зарабатывают деньги, а своими доработками(а провайдеры допиливают технологию, чтобы продавать получше) не делятся. Хотя, насколько мне известно, всеми любимый Яндекс таки контрибьютил в Redis.

И как-то так сложилось, что „картельный сговор“, состоящий из Amazon, Google Cloud, Oracle, а эти ребята далеко не последние по предоставлению облачных услуг, подсуетился и выпустил Valkey, в рамках которого планировалось дальнейшее развитие открытой кодовой базы редиски. Лицензия BSD, контроль проекта у Linux Foundation.

Сначала был просто форк, но осенью прошлого года вышел релиз Valkey 8.0, который решил:
1) пересмотреть подход к работе с потоками(да, редис не однопоточный в современных версиях, команды в один поток, но под сторонние активности потоки есть)
2) оптимизация хеш-таблиц — за счет предвыборки данных значения в бакете(хеш таблицы реализованы на методах закрытой адресации) и закидыванием их в кеш процессора(L1), избавились от последовательного чтения из оперативки. Может показаться, что экономят на спичках, но задержку сократили вдвое, звучит прекрасно.
3) починили репликацию — изменения на мастере, которые происходят, пока реплика оживает, теперь отправляются на реплику, а не хранятся на мастере.
4) немного память оптимизировали для словарей, но работает только при небольших размерах ключей.
5) докинули метрик — использование процессора, статистика по использованию ключей, метрики ввода/вывода по каждому слоту кластера. Теперь искать слоты с повышенной нагрузкой легче.

Хоть Redis и дал заднюю в 8 версии, сказав „цели и задачи ~~специальной~~ изменения лицензий достигли цели, вон эти халавщики выкинули свое детище в открытый мир, теперь мы вместе работаем на благо мира“ и Санфилиппо вернули, но телодвижения интересные, конечно.

Признавайтесь, была у кого паника в компании в прошлом году по этому поводу?

Я тут проект под ключ реализовал

Mon, 02 Jun 2025 23:58:08 +0300

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

С декабря месяца я взялся поднимать функциональность аналитики и отчетности в АСМ(это продукт, разработкой которого я занимаюсь). План был прост:
1) Собрать команду
2) Разобраться в устройстве корпоративных хранилищ данных, ведь аналитика и отчетность строится на каких-то данных, а данные еще нужно сложить и подготовить для отображения(привет data engineering).
3) Разобраться в моделирование бизнес-процессов для подготовки аналитических данных.
4) Сделать хранилище и смоделировать один бизнес процесс для обкатки выбранных подходов и инструментов.
5) Сделать отображение данных в графиках и таблицах.

И тут в целом можно было вспомнить, что я так-то бекенд разработчик, чем я тут вообще занимаюсь. Но вспоминать было некогда — работы вагон и еще три состава:
— Вместо одного бизнес процесса моделировать пришлось 5. Два месяца я засыпал и просыпался я в обнимку с томиком Кимбалла.
— Параллельно происходил ресерч и обоснование выбранных технологий для построения ETL-процессов и отображения данных, ресурсов на разработку собственных решений за отведенное время нет.
— Команда собрана. Нас пятеро друзей Оушена.
— Мы соответствуем РБПО, поэтому выбранные инструменты затянуты к себе и взяты на поддержку.
— Были подняты стенды для дев и целевой среды, так на свет родились deb-пакеты для Airflow и Superset, несуществовавшие в природе до этого. CI часть этого всего — это почти еще один продукт :)
— Разработаны ETL-процессы. Полностью. С нуля.
— Разработаны предустановленные отображения для данных. 6 страниц с кучей данных и переходами между друг другом, связанные общими фильтрами.
— Мы разворачиваемся у клиента с минимальными махинациями в админках используемых инструментов — так в dag-скриптах появились env’ы с подключением к БД и автоматический импорт дашбордов.
— Документация. Мы еще даже рассказываем, как при желании сделать собственные страницы с отчетами и как у нас там данные лежат.

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

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

Сделано столько работы, а это будто лишь начало пути.

Примеры применения LLM в больших компаниях

Wed, 28 May 2025 21:59:17 +0300

(Комментарий к посту )
Маты заблюрить к сожалению не могу, поэтому прошу простить.

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

Пока я будто вижу один большой стеб вайбкодеров и разговоры вокруг да около, за исключением генерации картинок и видео( меня очень зацепил сгенерированный роман «Ангельский двигатель», прикольно сделано). Как крутой поисковик тоже сойдет, по сути сейчас точка начала моего ресерча в неизвестных мне темах начинается с запроса в дипсик, а дальше раскручиваю по старинке.

У вас есть сохраненные примеры успешного внедрения LLM у каких-либо компаний? Поделитесь, буду признателен 👀

Замена циклов

Wed, 28 May 2025 21:57:41 +0300

Есть вещи из моей практики C++ программиста(кроме статической типизации), по которым я скучаю.
Например по алгоритмам из стандартной библиотеки.

Вот на примере кусок кода все из той же Chromium OS, который двигает панели.

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

Суть в очень красивом, по моему мнению, и лаконичном подходе с использованием обобщенного программирования или дженериков в простонародье. Насильно все к ним приводить не стоит, но уместное использование сильно режет количество кода. Меньше кода — меньше https://dimasmotrov.ru/all/menshe-znaesh-krepche-spish/ потенциального места для ошибок.

В питонячьей среде дженерики тоже есть, но вот аналога stl нет, да и не будет его. А мест, где нужно итерироваться по коллекциям, тьма. Пишем for дальше, что поделать 💻

Меньше знаешь — крепче спишь

Wed, 28 May 2025 21:55:11 +0300

Фраза спорная, но в написании кода помогает: несколько раз за последние 2 недели ловил себя на смешной ошибке, когда автодополнением кода вставлял имя не той переменной, которое требовалось.

В моем случае ошибки относительно безобидные — несколько раз в логи вместе поля computer_uid я писал просто uid. В будущем это явно бы могло сыграть со мной злую шутку, если бы пришлось решать проблему на стороне клиента.

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

Можно себя обезопасить, задав себе вопрос: а не слишком ли много знает этот кусочек кода/класс/подпрограмма?

Если много — то уберите лишний контекст, дайте ровно столько данных, сколько нужно. Дадите больше данных — можете их криво использовать.

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

Отберите у себя возможность ошибки, как родители отбирали у вас провод от компьютера в детстве💻

Очередной повод все переписать

Wed, 28 May 2025 21:53:43 +0300

За последние пару недель несколько раз в моем инфополе проскочило понятие «файбер», например:
— в руби решили сделать асинхронный веб-сервер с их использованием;
— в пикодате для многозадачности в рамках одного потока решили использовать файберы;
— в php их затащили оказывается уже как 4 года.

У меня закралась мысль: а не начнется ли сейчас поток статей и докладов с преподнесением файберов как решения всех проблем? По аналогии с микросервисами для решения проблем монолитов или же использования Golang для решения проблем корпоративной разработки.

Будет забавно, если в будущем увижу что-нибудь подобное 🙂

Режем ветки или сокращение использование ветвления

Wed, 28 May 2025 21:45:32 +0300

Качество видео слабое, запись старая

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

Если переносить чистый математический алгоритм в код, возможно настолько прямой подход будет хорош — запрятать код куда-нибудь в нижние уровни абстракций, куда пропуск по отпечатку пальца или же по цитированию рандомного алгоритма из книжек Кнута, сократить число вносимых изменений в подобный фрагмент и жить спокойно. Но что-то мне подсказывает(да и не только мне), что жестких алгоритмических задач мы уже давно не решаем, а больше крутим бизнес логикой приложений и функциональностью «принеси, подай, ...».

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

if something:
    if something_else:
        # do

писать

if something and something_else:
  # do

Отказ от else ветки условий сюда же. Из недавного на ревью:

if current not in cache:
  # do
else:
  # do

меняем на

if current not in cache:
  # do
  return / continue
# do else

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

SqlAlchemy в ETL процессах

Wed, 28 May 2025 21:30:10 +0300

На прошлой неделе затягивал алхимию в dag-скрипты для airflow. Так как AF не хостится на нашей стороне, а доставляется до заказчика, хотелось обойтись без использования внутренних соединений с БД(я про connections внутри AF) и написания SQL-запросов в plain-тексте дабы сохранить единообразие кодовой базы с обычными нашими сервисами по максимуму.

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

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

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

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

Дешевое и приятное решение, почаще бы таких :)

Есть у меня такой фетиш...

Wed, 28 May 2025 21:26:32 +0300

Есть у меня такой фетиш раз в три-четыре месяца обновлять конфиги для своего редактора(пишу я в neovim). Фетиш этот вынужденный, так как раз в 3-4 месяца обязательно что-нибудь ломается. Приколов с конфигом, который казалось бы написал один раз и изредка допиливаешь, если нужно что-то подтюнить, было масса.

Позавчера я подключал tailwind для проекта, подключил 4 версию. У меня отвалились подсказки редактора по классам стилей, подумал, что раз обновилась библиотечка, то нужно обновить плагин для подсказок этой чудесной либы. Решил за одно обновить все плагины, так как сейчас пользуюсь LazyVim(менеджер плагинов), сделать это достаточно просто.

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

С — стабильность :)

P.S. Обновил конфиг (ссылка на него), описание поправлю в процессе, кому интересно поглядеть — прошу :)

Потерянный прием в структурах данных

Wed, 28 May 2025 21:22:27 +0300

Решил систематизировать навыки по объектно-ориентированному анализу и проектированию(это про то, как проектировать ПО на основе АТД и их взаимодействия), наткнулся на следующий хороший прием для линейных структур данных(список, массив), как понятие курсора.

Курсор всегда указывает на какой-либо узел, если список(возьмем его для примера) не пуст. Есть набор операций, который применяется к узлу курсора(такой узел называют текущим). На картинках как раз эти методы, есть еще remove, который не поместился в скрин.

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

Сейчас конечно стандартной реализации списков во всех языках хватает — пару раз пробежаться по списку всякими map’ами и готово, особых манипуляций с гибким наполнением не требуется. Но меня удивило, что только сейчас наткнулся на подобный прием в контексте структур данных.

Да, в драйверах подключения к БД, да в той же алхимии, понятие курсора есть. Почему не упомянуть его в курсах по алгоритмам — вопрос, прикольно ведь.

Старое фото автора

Wed, 28 May 2025 21:16:46 +0300

Случайно нашел свою фотографию 6-летней давности