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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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