Как часто вы парсите Excel-таблицы? Лично я очень часто. И почти никогда эти файлы не выглядят так, что их можно без боли скормить pandas и сразу получить аккуратный DataFrame.
Думаю, многим знакома ситуация, когда: - таблица начинается где-то с 7-й строки - заголовок размазан на несколько рядов - названия колонок незначительно отличаются от файла к файлу
Со временем я все больше усложнял и полировал код парсинга, стараясь сделать его читаемым и поддерживаемым.
Буквально пару недель назад, проводя код-ревью, меня внезапно накрыло осознание: огромный кусок логики наших мини-приложений - это чтение и парсинг Excel-файлов. При этом целая команда разработчиков решает одну и ту же задачу, но каждый по-своему.
Стало немного больно.
Поэтому я написал xlea
xlea - это легкая библиотека, которая в духе SQLAlchemy или pydantic позволяет декларативно описывать схему таблицы и парсить Excel-файлы без танцев с бубном.
Неважно:
- с какой строки начинается таблица - с первой или с двадцать пятой - сколько строк занимает заголовок - одна или семь
Вы просто описываете схему, а дальше происходит магия.
Как это выглядит
Пример таблицы
Допустим, у нас есть Excel-файл, где таблица начинается где-то с пятой или десятой строки, это не принципиально. Выглядит она, скажем, так:
Предположим, нам нужны только: - номер сотрудника - ФИО - возраст
При этом: - ФИО может называться ФИО, Ф.И.О, Ф. И. О и как угодно еще - возраст в одних файлах просто Возраст, а в других Возраст сотрудника
Описываем схему
Начнем со схемы:
Мы создаем класс Person, наследуемый от Schema, и с помощью Column привязываем колонки таблицы к атрибутам:
id: колонка Номер сотрудника fullname: ФИО, описанное через регулярное выражение age: Возраст, который определяется через лямбда-функцию по имени столбца
Для age я также добавил валидатор: он проверяет, что значение числовое. Если строка не проходит валидацию, она будет пропущена (skip_invalid_row=True).
По умолчанию, если значение не проходит валидацию, парсинг останавливается с ошибкой InvalidRowError.
На этом схема готова, дальше можно парсить файл.
Парсим файл
Есть два варианта.
Вариант первый: автораспознавание.
В xlea встроены три ридера: openpyxl, xlrd и pyxlsb. Нужный выбирается автоматически по расширению файла:
Вариант второй: свой провайдер.
Можно реализовать протокол xlea.providers.proto.ProviderProto и передать его напрямую:
В протоколе нужно реализовать всего один метод - rows, который возвращает Iterable[Iterable]. То есть это может быть любой источник данных, не только Excel.
Таким образом, xlea полностью независима от конкретных ридеров. Вы можете: - реализовать чтение любых форматов файлов - расширять функциональность под свои нужды
Также можно подключить свой провайдер к механизму автораспознавания:
После этого autoread будет использовать MyProvider для файлов с нужным расширением.
Результат парсинга - итератор объектов Person:
Можно:
- обращаться к атрибутам напрямую - получить индекс исходной строки (row_index) - получить словарь через asdict()
Многоуровневые заголовки
Иногда таблицы выглядят так:
Здесь столбцы объединены в группу «Работа». Парсится это тоже довольно просто:
В декораторе config указываем количество строк заголовка, а уровни заголовков в Column разделяем символом ; (его тоже можно переопределить параметром delimiter в конфиге).
Всем привет! Команда Qwen от Alibaba выложила в открытый доступ Qwen3-TTS — нейросетевую модель для синтеза речи с клонированием голоса. Сегодня хочу рассказать об этой технологии подробнее и поделиться портативной версией.
Меня зовут Илья, я основатель сервиса для генерации изображений ArtGeneration.me, блогер и просто фанат нейросетей. А еще я сам собрал портативную версию Qwen3-TTS под win11 и успел её как следует протестировать.
Главная особенность системы в том, что она умеет не только озвучивать текст готовыми голосами, но и клонировать любой голос по короткому образцу, а ещё создавать новые голоса по текстовому описанию.
В основе Qwen3-TTS лежит End-to-End архитектура с дискретным многоканальным токенизатором речи (12.5 Гц, 16 слоёв). В отличие от традиционных систем, которые работают по цепочке "текст → фонемы → звук" и теряют информацию на каждом этапе, здесь всё обрабатывается одним махом.
Такой подход полностью исключает эффект "роботизированности" и каскадные ошибки генерации. Модель сохраняет интонации, эмоции и особенности тембра.
9 встроенных голосов разных типов — молодые и зрелые, мужские и женские. Можно управлять эмоциями и стилем речи через текстовые инструкции.
Создание голоса по описанию (VoiceDesign)
Описываете словами, какой голос нужен — модель его генерирует. Например: "молодой женский голос, игривый, с высоким тоном". Лучше работает если писать промпты на голос на английском.
Клонирование голоса (Voice Clone)
Загружаете аудио от 3 секунд — получаете синтез этим голосом. По бенчмаркам качество клонирования превосходит ElevenLabs и MiniMax по показателям сходства спикеров. Оно и правда веского качества, уровень VibeVoice, но гораздо легче по ресурсам.
NVIDIA GPU с 8+ ГБ видеопамяти (или CPU, но медленнее)
Windows 10/11 64-bit
16 ГБ оперативной памяти
20 ГБ свободного места на диске
Текущие ограничения
Ударения иногда расставляются неправильно
С длинными текстами могут быть проблемы
Инструкции для VoiceDesign лучше писать на английском
Распакуйте в корень диска (путь без кириллицы), запустите install.bat. Модели скачаются при первом запуске. А если будут сложности в установкой в посте в канале найдете версию с уже установленным env (окружением).
Я рассказываю больше о нейросетях у себя на YouTube, в телеграм и на Бусти. Буду рад вашей подписке и поддержке. Ну и на канал Нейро-Софт тоже подпишитесь, чтобы не пропустить полезные репаки. Всех обнял и удачных генераций!
После установки надо перезагрузить страничку или же перезапустить браузер, чтобы начало считать, пока хз как это поправить.
Идея появилась очень приземлённо. Я много лет сижу за компом. Код, браузер, тексты. И в какой-то момент поймал себя на мысли: мышь я в руках держу больше, чем что-либо ещё, а про неё не знаю вообще ничего.
Сколько кликов в день? Сколько раз я просто бессмысленно вожу курсором? Сколько «километров» уже накатал за годы?
Полез в Chrome Store — либо тайм-трекеры с кучей лишнего, либо вообще не то. Простого «посчитать мышь» нет.
Ну окей, значит сделаю сам.
Что сделал
Расширение:
считает клики
считает прокрутку
считает пробег курсора (да, в метрах и километрах)
работает локально
ничего никуда не шлёт
висит в фоне и не мешает
Без аккаунтов, аналитики, «улучшим вашу продуктивность» и прочего маркетинга.
В процессе
Самое интересное было не написать код, а решить мелочи:
как считать движение, а не микродрожь
как не грузить браузер
как показать цифры так, чтобы они были читаемы даже на маленькой иконке
Типичный инженерный пет-проект: половина времени уходит на «а вот тут неудобно».
Выложил в Chrome Store
Выложил без особой надежды на публикацию — думал, у них таких заявок сотни, и мою глупую идею просто отсекут. Но нет, через неделю пришло уведомление: расширение опубликовано! Вот это было круто — реально порадовало.
Пока пользователей всего двое, но всё равно приятно. Теперь хочу поделиться проектом с сообществом Пикабу — вдруг кому-то тоже будет интересно.
Проект с открытым исходным кодом
Сейчас расширение стало опен-сорс проектом. Код открыт, и если кому-то интересно — можно присоединиться на GitHub. Буду рад любым идеям, пулл-реквестам и просто общению.
Давно хотелось сделать что-то, где разные программисты могут вместе развивать простую, но любопытную идею. Есть мысли: не просто считать движение мыши, а анализировать «энергию» пользователя, эмоциональное состояние, добавлять разные метрики и визуализации.
Если тебе близка тема open source и хочется поэкспериментировать — добро пожаловать.
В этой статье я хочу поделиться своим опытом и первыми шагами в Open Source-разработке. Свой путь я начал в начале 2025 года и за это время мои проекты в сумме набрали более 200 звёзд на GitHub.
За прошедший год мне удалось выпустить несколько релизов, выстроить базовые процессы тестирования, а также привлечь первых контрибьюторов к своим проектам.
Я не считаю свой опыт в Open Source разработке большим, однако уверен, что некоторые наблюдения и практические советы могут быть полезны тем, кто только планирует начать свой путь, а также разработчикам, которые уже делают первые шаги в открытых проектах.
Основной фокус статьи будет направлен на процессы разработки: с какими трудностями я столкнулся, какие решения оказались удачными и на какие аспекты, на мой взгляд, стоит обратить внимание на ранних этапах создания Open Source-проекта.
Большинство Open Source-проектов создаётся не с целью прямой монетизации, а ради социального признания. К таким показателям можно отнести звёзды на GitHub, лайки и подписчиков в социальных сетях. Эти метрики позволяют получить внешнюю оценку проделанной работы и, в определённой степени, повысить свою заметность на рынке.
Прямой финансовый доход от подобных проектов, как правило, не предполагается. Возможны донаты или спонсорская поддержка, однако на начальных этапах разработки не стоит рассчитывать на значительный заработок.
Исходя из этого, я рекомендую начинать с проектов, которые полезны вам лично. В таком случае у вас появляется естественная мотивация поддерживать и развивать проект, даже если внешняя обратная связь минимальна.
Отдельное внимание стоит уделить масштабу проекта. Оптимальное время разработки до первой MVP-версии не должно превышать 1–2 недель. Более длительный цикл без ощутимого результата значительно повышает риск выгорания и потери интереса к проекту.
Для вдохновения вы можете посмотреть проекты которые сейчас в тренде на GitHub или подписаться на Topic по интересующему вас направлению (https://github.com/trending).
Выбор аудитории
При создании Open Source-проекта важно заранее определить целевую аудиторию, поскольку от этого решения будет зависеть практически вся дальнейшая разработка.
В общем случае проекты можно условно разделить на два типа:
проекты для разработчиков;
проекты для конечных (сторонних) пользователей.
На этапе планирования необходимо чётко понимать, для кого именно создаётся продукт, так как выбранная аудитория напрямую влияет на архитектуру, набор функций, требования к документации и способы распространения проекта.
Проекты для разработчиков
Если вы разрабатываете библиотеку, фреймворк или инструмент для разработчиков, имеет смысл ориентироваться на технологии, которые востребованы на рынке. Использование популярных языков программирования и экосистем, как правило, позволяет охватить более широкую аудиторию.
Однако существует и альтернативный подход: вместо выбора языка можно отталкиваться от актуальных рыночных трендов. Например, изучить популярные проекты и экосистемы и создать для них вспомогательную библиотеку, плагин или интеграционный шлюз.
В таком случае даже использование менее распространённого языка программирования может стать преимуществом: конкуренция будет ниже, а проект сможет привлечь значительную аудиторию за счёт решения актуальной задачи. Типичный пример — разработка полезного инструмента или библиотеки для новой технологии или нейросети, которая находится на пике интереса.
Проекты для конечных пользователей
Если проект ориентирован на пользователей, не связанных с разработкой (как в моём случае), приоритеты смещаются. Здесь особенно важно уделять внимание:
производительности и оптимизации;
качественной и понятной документации;
простоте установки и быстрому развёртыванию проекта.
Необходимо учитывать, что такая аудитория, как правило, не имеет технического бэкграунда. Поэтому ключевой фактор успеха — минимальный порог входа и понятный пользовательский опыт.
Наблюдения из практики
По моему опыту, проекты для разработчиков чаще получают звёзды на GitHub, поскольку их аудитория хорошо ориентируется в экосистеме платформы и активно использует такие метрики. Однако подобные проекты сложнее продвигать и выделять среди конкурентов.
Проекты для конечных пользователей, в свою очередь, обычно получают меньше звёзд, но их аудитория охотнее идёт на контакт и более заинтересована в развитии продукта, особенно если он напрямую влияет на их бизнес-процессы.
Начало разработки
На ранних этапах разработки важно сразу продумать сценарий использования проекта с точки зрения пользователя. В идеале процесс установки и первичной настройки не должен превышать 2–3 шага — чем ниже порог входа, тем выше вероятность, что пользователь действительно попробует ваш продукт.
Если вы разрабатываете библиотеку, имеет смысл ориентироваться на популярные менеджеры пакетов соответствующей экосистемы. Это позволяет пользователям подключать ваше решение к проекту с помощью нескольких команд в терминале, без дополнительной ручной настройки.
Если же проект представляет собой отдельный сервис (как в моём случае), стоит заранее задуматься о контейнеризации. Использование Docker позволяет изолировать зависимости, стандартизировать окружение и значительно упростить процесс установки и запуска проекта.
В процессе разработки проекта tg-support-bot я предусмотрел два варианта установки:
Полный вариант — развёртывание через docker-compose, включающее все необходимые сервисы: PostgreSQL, PgAdmin, Loki, Grafana, Redis и другие компоненты.
Упрощённый вариант — установка проекта на обычный хостинг с возможностью подключения внешней базы данных и отключения необязательных сервисов.
При этом важно избегать жёстких зависимостей между контейнерами. Пользователи должны иметь возможность отключать или заменять отдельные сервисы внутри docker-compose без нарушения работоспособности основного приложения.
Линтинг, настройка CI и тесты
Перед публикацией проекта важно настроить надежную систему тестирования и линтинга. Это помогает предотвратить ошибки, повышает стабильность проекта и облегчает совместную разработку.
Code style и линтеры
Для каждого проекта важно определить и задокументировать правила code style. Чем строже и однозначнее эти правила, тем проще поддерживать читаемость кода и единый стиль среди участников проекта.
Также необходимо настроить линтеры, которые проверяют код на:
синтаксические ошибки и типизацию;
соответствие имен переменных и функций выбранному стилю;
распространённые ошибки и потенциальные уязвимости.
Автоматическое тестирование
Автотесты критически важны для поддержания стабильности проекта и ускорения разработки. Чем больше функций покрыто тестами, тем безопаснее вносить изменения и привлекать сторонних контрибьюторов.
В проекте tg-support-bot я реализовал систему shell-скриптов для автоматизации линтинга и тестирования с передачей дополнительных параметров к инструментам анализа.
Скрипты интегрированы с git-хуками:
При коммите запускаются проверки только для файлов, включённых в индекс.
Статический анализатор PHPStan проверяет код на ошибки и нарушения типизации;
Выполняются unit-тесты для изменённых классов;
Если изменён Dockerfile, запускается Hadolint для проверки Dockerfile;
Если изменены shell-скрипты, применяется ShellCheck для выявления ошибок и потенциальных уязвимостей.
При push выполняется проверка всего проекта: PHPStan анализирует весь код, запускаются все unit-тесты и линтеры. Это позволяет выявить проблемы, которые могли быть пропущены при коммите.
На этапе CI система повторно проверяет весь проект, что особенно важно для Open Source: сторонние контрибьюторы могут внести изменения, которые нарушат работу проекта.
Пример работы CI в проекте tg-support-bot
В случае обнаружения ошибки системы блокирует изменения до исправления ошибок.
Таким образом, процесс тестирования делится на три уровня:
Локальная проверка при коммите — только файлы, добавленные в коммит.
Проверка при push — весь проект для предотвращения глобальных ошибок.
CI/CD — полная автоматическая проверка, включая сторонние изменения.
Продуманная система тестирования и линтинга позволяет снизить риски и обеспечивает стабильность проекта, что особенно важно в Open Source-разработке.
Структура GitHub репозитория
В процессе разработки вы будете создавать множество веток, которые в дальнейшем будут сливаться с основной веткой main. От правильной организации веток напрямую зависит качество проекта и удобство командной работы.
Структура веток
На своих проектах я использую следующую схему:
Ветка main является основной. Прямые коммиты в неё запрещены — все изменения вносятся через дочерние ветки.
Релизные ветки создаются перед планированием релиза. Например, для шестого релиза создаётся ветка release_6. В этой ветке я фиксирую все задачи, которые должны войти в релиз.
Ветки задач создаются для каждой отдельной задачи из релиза. В наименовании ветки обязательно указывается номер соответствующего Issue. Это строгое правило: ветка с некорректным именем не пройдет проверки CI, и изменения не смогут быть слиты в проект.
Такой подход помогает:
Приучиться создавать Issues для любых изменений;
Контролировать работу сторонних контрибьюторов;
Поддерживать прозрачность процесса разработки.
Пример описания коммитов
Структура коммитов
Для упрощения отслеживания изменений я использую shell-скрипты, которые автоматически:
Добавляют в начало описания коммита номер задачи (issues-62 | update tests);
Формируют список изменённых файлов с пометками Added, Changed, Deleted.
Также важно соблюдать грамотное описание релизов: каждая версия должна содержать чёткий список изменений и исправленных задач. Такой подход обеспечивает:
прозрачное ведение истории изменений;
удобство для контрибьюторов и пользователей;
облегчение поддержки проекта в долгосрочной перспективе.
Строгая структура веток и коммитов повышает контроль над изменениями, улучшает читаемость истории проекта и минимизирует ошибки при совместной разработке в Open Source.
Документирование
Документирование — один из ключевых аспектов Open Source-разработки. Хорошая документация делает проект доступным для пользователей и контрибьюторов, ускоряет внедрение и снижает количество ошибок при использовании.
Формат: версия, дата релиза, исправления, новые функции.
Отдельно хочу выделить раздел Wiki на GitHub...
GitHub Wiki — это встроенный инструмент для более подробной и структурированной документации проекта. В отличие от README, Wiki позволяет создавать несколько страниц, объединённых логической структурой, что удобно для больших проектов.
Использование Wiki целесообразно для расширенной документации: здесь можно описать архитектуру проекта, инструкции по деплою и CI/CD, гайды по использованию библиотек и сервисов, а также рекомендации для контрибьюторов. Важно, чтобы Wiki дополняла README, а не дублировала его, оставляя последний кратким и ориентированным на быструю установку и запуск.
Практические рекомендации
Документируйте всё ключевое сразу, не откладывая на будущее. Это экономит время и снижает риск потери информации.
Используйте шаблоны и стандарты (например, Markdown, OpenAPI, DocBlock), чтобы документация была однородной.
Поддерживайте документацию в актуальном состоянии — каждая новая функция или изменение должно сопровождаться обновлением описаний.
Для сторонних пользователей делайте упор на простоту и понятность, для разработчиков — на технические детали и примеры использования.
Взаимодействие с аудиторией
Для успешного развития Open Source-проекта важно активно взаимодействовать с аудиторией и привлекать пользователей из сторонних источников. Это помогает не только продвигать проект, но и получать ценные отзывы для улучшения функционала.
Первым шагом является выбор удобного канала коммуникации. Это может быть форма обратной связи на сайте, отдельная почта для обращений пользователей или группа в популярной социальной сети. Главное — чтобы пользователи могли легко задавать вопросы и получать ответы.
В проекте tg-support-bot я создал отдельную группу, где публикую новости, отвечаю на часто задаваемые вопросы и взаимодействую с пользователями.
Этот подход оказался очень эффективным: со временем пользователи стали помогать друг другу, отвечая на вопросы без моего участия. Кроме того, участники активно тестируют новые функции, выявляют ошибки и предлагают улучшения, что значительно ускоряет развитие проекта.
Дополнительно в Telegram-группе я получаю от пользователей идеи для нового функционала и провожу голосования, что позволяет учитывать мнение сообщества при планировании развития проекта.
Таким образом, налаженная коммуникация с аудиторией позволяет объединить пользователей, повысить вовлечённость и создать сообщество вокруг проекта, что является ключевым фактором успешного Open Source-развития.
Скриншот из группы TG Support Bot | Бот для технической поддержки
Популяризация проекта
Для расширения аудитории важно привлекать пользователей из внешних источников. Одним из эффективных способов является создание видеоконтента в формате «Dev-блог», где можно показывать процесс разработки и делиться опытом по созданию проекта.
Видеоинструкции по установке и настройке проекта также оказывают большую помощь пользователям, снижая порог входа и повышая интерес к проекту.
Дополнительно полезно публиковать статьи на популярных ресурсах, таких как Хабр или Пикабу, чтобы привлечь новую аудиторию и рассказать о проекте более широкой публике.
Если проект содержит интересные технические решения, он может привлекать внимание даже тех пользователей, которые не планируют использовать его напрямую, но хотят наблюдать за процессом разработки и изучать технические детали.
Заключение
Open Source — это не только код, но и процессы, сообщество и взаимодействие с пользователями. Продуманная структура репозитория, тесты, документация и активная коммуникация помогают проекту развиваться и привлекать новых участников.
Если вам интересно следить за моими проектами и участвовать в их развитии, подписывайтесь на мой GitHub — там вы найдёте все обновления и сможете присоединиться к работе над проектами.
ASEPRITE и LibreSprite - два редактора для создания пиксельной графики и анимации, связанные общей историей. ASEPRITE изначально распространялся как открытое ПО под лицензией GPL, но в 2016 году разработчики перевели его на платную проприетарную модель ради монетизации. В ответ на это сообщество создало LibreSprite - бесплатный форк последней открытой версии оригинального редактора.
Главное различие между ними лежит в области лицензирования и философии. ASEPRITE теперь платный продукт с закрытым кодом, что обеспечивает стабильное финансирование разработки. LibreSprite остаётся бесплатным и открытым, следуя принципам свободного программного обеспечения.
По базовому функционалу оба редактора практически идентичны - анимация, луковая шелуха, стандартные инструменты для пиксель-арта присутствуют в обоих. Однако ASEPRITE быстрее получает новые возможности благодаря коммерческой модели, тогда как LibreSprite развивается силами энтузиастов, и темп обновлений там обычно ниже. Поддержка тоже различается: у ASEPRITE есть официальная документация и техподдержка, а пользователи LibreSprite полагаются на форумы и Discord-сообщество.
