В этот раз мы рассмотрим операции своеобразного «деления функторов». Начнём с обобщения задачи поиска сопряжённых функторов, но потом убедимся, что расширения Кана являются фундаментальной абстракцией, лежащей в основе множества полезных инструментов.
Всем привет!
В этой статье мы рассмотрим микросервис для управления файлами 3D туров по музеям, написанный на Go. Будет представлен код сервиса, который выполняет набор некоторых манипуляций с zip архивам, в том числе основную задачу, а именно распаковку и загрузку их в S3 хранилище.
Алгоритм Slug, используемый для рендеринга на GPU шрифтов непосредственно из кривых Безье, был разработан осенью 2016 года, а значит, в этом году мы отмечаем десятилетие его рождения. В середине 2017 года я опубликовал в JCGT статью об этой методике, а вскоре после этого моя компания продала первую лицензию на версию 1.0 Slug Library. С тех пор Slug многократно лицензировался разработчиками видеоигр, а также компаниями, специализирующихся в научной визуализации, CAD, редактировании видео, медицинском оборудовании и даже создании планетариев. Среди наших клиентов Activision, Blizzard, id Software, 2K Games, Ubisoft, Warner Brothers, Insomniac, Zenimax и Adobe. Slug оказался моим самым успешным программным продуктом.
Изначально я создавал Slug с целью улучшения рендеринга текста в C4 Engine, шрифты которого должны выглядеть идеально не только в GUI, но и внутри игровых уровней, где они могут быть очень крупными и отображаться под разными углами. Недавно я использовал Slug в создании редактора формул Radical Pie, в котором, разумеется, необходим крайне качественный рендеринг шрифтов, а также векторной графики для таких обозначений, как скобки, знаки корня и чисто графических элементов наподобие стрелок и выделения математических выражений. Кроме того, Slug используется для рендеринга всего интерфейса пользователя внутри основного окна редактирования и всех диалоговых окон.
В этом посте я расскажу об изменениях в методике рендеринга с 2017 года, когда была опубликована научная статья и выпущена первая версия Slug Library. Завершается статья важным объявлением для тех, кто захочет реализовать алгоритм Slug в собственных проектах.
Привет, Хабр!
Менеджеры продаж не всегда вовремя и полно заносят данные о сделках в CRM после звонка. Часть информации может забыться, а часть может быть записана сокращенно.
Прослушивать звонки вручную и восстанавливать детали слишком трудоёмко, а ресурсов на это часто не хватает. Поэтому в этом материале соберём MVP-сервис на Python, который получает событие о завершённом звонке из МТС Exolve, забирает текст разговора, выделяет из него ключевые поля через YandexGPT и записывает результат в Bitrix24. На выходе получится рабочий пайплайн: вебхук, транскрибация, извлечение полей квалификации и обновление существующей сделки в CRM.
За основу возьмём BANT — базовый фреймворк квалификации лида: Budget, Authority, Need, Timing, то есть бюджет, лицо, принимающее решение, потребность и сроки. И расширим его, добавив оценку интереса клиента, фиксацию конкурентов и возражений. Такого набора достаточно, чтобы квалифицировать лид, приоритизировать сделку и сохранить контекст следующего контакта, но не превращать карточку в анкету на десятки полей.
Стек: Python 3.10+, Flask, SQLite, Call Transcribation API МТС Exolve, YandexGPT API, Bitrix24 REST API.
Последнее время я экспериментировал с AI-агентами на Raspberry Pi 5.
И довольно быстро столкнулся с проблемой: большинство существующих агентных фреймворков оказываются слишком тяжёлыми для небольшого железа.
С задачей построения платформы для потоковой обработки данных по тем или иным причинам сталкиваются многие компании. И довольно часто подобная разработка превращается в попытку «создать ракету», не понимая сути происходящего под капотом. При этом для решения подобной задачи достаточно иметь набор инструментов и знать принципы их настройки на каждом из этапов.
Меня зовут Сергей Емельянов. Я руководитель Core-команды VK Tech. В этой статье я пошагово покажу процесс построения синтетической платформы для обработки потоковых данных на Kubernetes.
Здравствуйте, дорогие читатели! Сегодня я расскажу вам о проекте hornbeam, который переводится на русский язык как "граб" - это такое дерево, похожее на дуб. Он позволяет деплоить сервисы на питоне, используя для этого виртуальную машину эрланга, BEAM (!) А также, позволяет удобно запускать код на питоне, если вы уже используете Erlang или Elixir.
Фреймворк, на мой взгляд - полностью в духе эпохи, в которой доминируют питон, дата-саенс, машинное обучение и LLM, и в которой в программирование продолжают проникать полупрофессиональные инструменты из среды дата-саентистов и других энтузиастов - к счастью. Дошло уже до того, что инструменты и практики с почти безупречной репутацией, такие как kubernetes и контейнеризация, уступают место крайне любительскому подходу вроде "для инфраструктуры используйте эрланг".
Проект задумал и осуществил автор широко известного веб-сервера gunicorn, он адресован широкому сообществу программистов на питоне и эрланге.
Почти три года я в одиночку строил бэкенд-фреймворк поверх Next.js App Router. По дороге мой ишью закрыл создатель C#, синтаксис подсказал Copilot, а три пакета-адаптера пришлось убить. Рассказываю, что вышло и какие грабли собрал.
Первый формат своей диаграммы Генри Л. Гант разработал аж в 1910 году — на бумаге. Сейчас ленточные диаграммы строят в специальных приложениях, сервисах для управления проектами, типа Trello или Jira, конечно же, в Excel, и в том числе в нашем любимом 1C. Об этом и поговорим.
Привет, Хабр! Меня зовут Мирослава Косенко. Я разработчик 1C в IBS. В этой статье расскажу, как диаграмма Ганта помогает визуально планировать, контролировать и анализировать процессы, будь то производство, проектные задачи или цепочки этапов в учетных подсистемах. Разберемся, что из себя представляет диаграмма и какие проблемы она помогает решать. Посмотрим на реальные примеры использования и обсудим нетиповые кейсы, а также шаг за шагом разберем, как создать и настроить диаграмму Ганта в 1С. Особое внимание уделим нюансам разработки: какие элементы доступны, как они взаимодействуют, какие подводные камни возникают и как их обходить.
Статья будет полезна аналитикам, консультантам и разработчикам, планирующим внедрять диаграмму Ганта в своих проектах или улучшать уже существующие решения.
Привет, Хабр! Я — Владимир Балун, и это — вторая часть материала о пакете с отпугивающим названием «unsafe» в Go и том, чем он может быть реально полезен. В первой части мы рассмотрели его содержимое, особенности и нюансы, оптимизации кода с использованием unsafe — все это вы можете освежить в памяти по ссылке.
Сегодня перейдем непосредственно к той самой «магии»: трюки, хаки, советы и лучшие практики с моей стороны.
Распараллеливаем процесс вставки данных в PostgreSQL при помощи Spring с сохранением атомарности всей операции
Разработчики часто сталкиваются с проблемами производительности своих систем. Один из привычных способов ускорить медленный бизнес-процесс — распараллелить его. Это почти всегда работает: чем больше потоков обслуживают задачу, тем быстрее она выполняется.
Но когда речь заходит о вставке данных в PostgreSQL, возникает проблема: распараллеливание действительно ускоряет операцию, но ломает ее атомарность. Данные начинают появляться в таблице частями. Для многих бизнес-процессов это неприемлемо — нужно, чтобы вся пачка данных становилась доступной одновременно.
В этой статье расскажу о том, как сделать вставку данных одновременно многопоточной и атомарной.
В данной статье рассматриваются примечательные ошибки при работе с Kafka, в том числе при использовании библиотеки KafkaJS, а также способы их устранения и методы увеличения производительности при публикации и обработки сообщений.
Предполагается, что читатель имеет базовое представление о Kafka (раздел "Общие термины" поможет освежить информацию) и функционале библиотеки KafkaJS.
В первой части разбираются аспекты, связанные с публикацией сообщений.
Vibe coding — это одновременно и мем, и реальность 2025-2026 года. Кто-то называет это будущим разработки. Другие считают, что это способ генерировать технический долг со скоростью света.
Мы решили попробовать создать коммерческий проект с нуля полностью с помощью вайбкодинга. В результате: 46 000 строк кода, полтора месяца, два человека. Проект работает, клиент пользуется.
Вообще как бы нифига себе – написать рабочую CRM, которая автоматизирует обработку входящих запросов и может автоматически работать по сделкам: отвечать на письма, ставить задачи, проводить сделку по воронке.
В какой-то момент я прогнал самоаудит по своему проекту и получил неприятную, но полезную картину.
В кодовой базе оказалось 41 034 метода и 2 170 файлов. Если считать только основной код, без тестов, 12 093 метода из 19 880 были вообще без комментариев. Покрытие документацией получилось 39%.
Это не история про чужой легаси-проект. Это мой текущий код. Он просто рос быстрее, чем я успевал его объяснять.
На бумаге у меня всё было нормально: README, заметки по архитектуре, большой CLAUDE.md, отдельные пояснения по важным решениям. Но когда смотришь на реальные вопросы, которые возникают по ходу работы, быстро выясняется, что документация покрывает только часть из них.
Привет, Хабр!
Сегодня рассмотрим Send и Sync. Не «что это такое» (это вы в book прочитаете за пять минут), а как именно компилятор принимает решения, почему &mut T внезапно Sync, и что происходит, когда вы пишете unsafe impl Send.
С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.
Продолжу цикл по системе.
Чего хочется от ETL процесса?
Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.
Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.
В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.
Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.
Как бы нам это все замиксовать?
На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.
По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.
Когда читаешь новости про очередную миллиардную сделку (типа покупки Neon за $1 млрд), невольно задумываешься: а что такого ценного в этих базах данных? Вроде же есть PostgreSQL, MySQL - бесплатно, open source. Но нет, люди платят, и платят огромные деньги. Чтобы понять, за что, нужно заглянуть под капот. И начать не с распределённых монстров, а с самого простого - с одной-единственной ноды.
Последние несколько лет я только и делаю что целенаправленно избавляюсь от повторяющихся задач. Отчёты, копирование данных из таблиц, инвестиционный учёт, оплата счетов и даже мониторинг тех, кто звонит во входную дверь.
Но в какой‑то момент я понял, что для того чтобы всё это автоматизировать не нужна какая‑то единая сложная система. Достаточно небольших скриптов и связки трёх инструментов:
📍 Excel / Google Таблицы — как удобный интерфейс и база данных.
📍 Python — как универсальный автоматизатор.
📍 API — как пульт управления.
За годы у меня накопились десятки готовых скриптов и нестандартных решений. Я решил собрать их, систематизировать и выпустить в виде книги: «Excel, Python и API. Автоматизация данных и управление офисом, домом, финансами».
Рынок CRM-систем в России плотно занят: Битрикс24, amoCRM, Мегаплан и другие. Но к сожалению, бесплатных и открытых мало или возможно нет вовсе.
Open-source дает полный контроль над кодом, self-hosted развёртывание и возможность кастомизировать каждый компонент. Сэкономленные деньги с лицензии ПО можно потратить на дополнительную кастомизацию под себя или другие цели кампании.
Я создал FARA CRM — open-source CRM, построенную на современном стеке, запускающуюся одной командой из Docker.
Стек: Python 3.12+ · React 18.2.0 · FastAPI · Docker · PostgreSQL
Рефакторинг — это не уборка, это хирургия на живом коде. Большинство провалов здесь не технические: смешали рефакторинг с улучшениями, сделали один огромный коммит, затянули релиз — и три недели работы ушли в мусор. Собрал 10 ошибок из реальных проектов: с примерами кода, разбором механики и способами не наступить на те же грабли.