Программирование на python

Но пока я это делал, собрал пару залуп. О них и расскажу.
Первая залупа — хранение времени. Сначала я хранил напоминание строкой вида «13.08.2026 15:00» и сравнивал с текущей минутой. Работало, пока бот не перезапустился. После рестарта напоминания, которые должны были прийти в этот момент, просто терялись.

Перевёл на timestamp в миллисекундах и выборку remind_at <= now. Теперь даже если бот проспал — при следующей проверке догонит.
Вторая залупа — миграция базы. Поле remind_at не добавлялось в существующую таблицу через CREATE TABLE IF NOT EXISTS. SQLite так не умеет — нужен ALTER TABLE. А он падает, если колонка уже есть. Пришлось оборачивать в try/catch и игнорировать ошибку. Мелочь, а потратил час.

Третья залупа — форма выбора времени. Сначала сделал кривой input, который не открывал календарь. Потом сделал кнопку с нативным пикером — вроде заработало. Но при повторном открытии формы вместо сохранённого времени показывался «Invalid date». Оставил как есть — косметика, потом поправлю.

Итог:

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

Всё это — часть моего бота TG Notion. Там есть личные задачи, заметки, общие доски. Пользуйтесь.
Все обновления и внутренняя кухня - у меня на КАНАЛЕ!)

Сталкивались ли вы когда-нибудь с такой ситуацией: вы получаете PDF-отчёт на сотни страниц, пытаетесь переслать его коллеге, но вложение в письме превышает допустимый размер и отклоняется? Или вам нужна только конкретная глава, но приходится вручную извлекать её постранично из сотен страниц? Эти «громоздкие» файлы всегда доставляют головную боль при обмене, печати или архивировании. Решение на самом деле довольно простое — просто разделите PDF на несколько меньших файлов по требованию, и проблема решена.

В этой статье мы покажем, как использовать библиотеку Spire.PDF for Python для реализации двух основных режимов разделения с минимальным количеством кода: разделение на одностраничные PDF-файлы одним нажатием и гибкое разделение по произвольным диапазонам страниц .

Предварительные требования: настройка окружения и импорт библиотеки

Spire.PDF for Python — это профессиональный компонент для работы с PDF, который работает полностью независимо от внешних программ, таких как Adobe Acrobat, что делает его идеальным для интеграции в серверы или автоматизированные скрипты.

Команда установки:

pip install Spire.PDF

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

Режим 1: Разделение каждой страницы на отдельные одностраничные PDF-файлы

Если ваша бизнес-задача требует сохранить каждую страницу многодесятистраничного контракта, тендерной документации или электронной книги как отдельный PDF-файл, метод Split() является самым удобным выбором.

from spire.pdf.common import *

from spire.pdf import *

# 1. Инициализация и загрузка исходного PDF-документа

doc = PdfDocument()

doc.LoadFromFile("Sample.pdf")

# 2. Разделение: сохранение каждой страницы как независимого одностраничного PDF-файла

# {0} — это заполнитель номера страницы; второй параметр 1 указывает, что нумерация начинается с 1

doc.Split("Output/SplitDocument-{0}.pdf", 1)

# 3. Освобождение ресурсов

doc.Close()

Пояснение метода:

Полная сигнатура метода Split() — Split(string fileName, int startNumber), и его функция заключается в строго фиксированном разделении каждой страницы PDF на независимый одностраничный PDF-файл — это поведение нельзя изменить с помощью параметров.

Два параметра означают следующее:

• fileName : Путь для выходного файла и шаблон имени. {0} внутри является заполнителем, который будет автоматически заменён фактическим номером страницы при сохранении.

• startNumber : Задаёт начальный номер для заполнителя {0}. Он влияет только на нумерацию в имени файла и не имеет отношения к логике разделения .

Режим 2: Разделение по требованию путём выбора диапазонов страниц

Иногда нам не нужно разделять каждую страницу, а хочется разбить PDF на логические части. Например: Часть 1 (обложка) , Часть 2 (основной текст, главы 1–3) , Часть 3 (приложение) .

В этом случае мы можем создать несколько объектов PdfDocument и использовать метод InsertPageRange() для точного извлечения определённых страниц из исходного документа.

from spire.pdf.common import *

from spire.pdf import *

# Загрузка исходного документа

doc = PdfDocument()

doc.LoadFromFile("Sample.pdf")

# Создание трёх пустых PDF-объектов для хранения разделённого содержимого

newDoc_1 = PdfDocument()

newDoc_2 = PdfDocument()

newDoc_3 = PdfDocument()

# 1. Извлечение страницы 1 (обложка)

# Примечание: индексы страниц начинаются с 0, поэтому страница 1 соответствует индексу 0

newDoc_1.InsertPage(doc, 0)

# 2. Извлечение страниц со 2 по 4 (начало основного текста)

# Параметры InsertPageRange: (исходный_документ, начальный_индекс, конечный_индекс)

newDoc_2.InsertPageRange(doc, 1, 3)

# 3. Извлечение страниц с 5 по последнюю (оставшаяся часть)

# doc.Pages.Count получает общее количество страниц; вычитание 1 даёт индекс последней страницы

newDoc_3.InsertPageRange(doc, 4, doc.Pages.Count - 1)

# Сохранение трёх разделённых документов по отдельности

newDoc_1.SaveToFile("Output1/Split-1.pdf")

newDoc_2.SaveToFile("Output1/Split-2.pdf")

newDoc_3.SaveToFile("Output1/Split-3.pdf")

# Закрытие всех объектов документа для освобождения памяти

doc.Close()

newDoc_1.Close()

newDoc_2.Close()

newDoc_3.Close()

Правила индексации страниц (очень важно):

В Spire.PDF нумерация страниц следует общепринятому в программировании соглашению — начиная с 0 . То есть doc.Pages[0] представляет первую страницу PDF. Понимание этого критически важно для точного извлечения диапазонов:

• InsertPage(doc, 0): вставляет страницу 1.

• InsertPageRange(doc, 1, 3): вставляет страницы со 2 по 4 включительно.

• InsertPageRange(doc, 4, doc.Pages.Count - 1): начинается со страницы 5 и до физической последней страницы.

Преимущество такого подхода к разделению — его исключительная гибкость: вы можете комбинировать страницы по любым правилам или даже извлекать страницы из разных исходных файлов и объединять их в новый PDF (используя возможность InsertPage работать с разными документами).

Расширение: Разделение по фиксированным группам страниц

Стоит отметить, что метод Split() не может выполнить требование «объединять каждые N страниц в один PDF» (например, объединять каждые 2 страницы в один файл). Если вам требуется такое групповое разделение, необходимо использовать InsertPageRange в цикле для ручной реализации:

# Пример: объединение каждых 2 страниц в один PDF

group_size = 2

for i in range(0, doc.Pages.Count, group_size):

new_doc = PdfDocument()

end_index = min(i + group_size - 1, doc.Pages.Count - 1)

new_doc.InsertPageRange(doc, i, end_index)

new_doc.SaveToFile(f"Output/Group-{i // group_size + 1}.pdf")

new_doc.Close()

Рекомендации по выбору между двумя режимами

Заключение

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

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

До IT я работала в другой сфере, а программирование для меня долго было чем-то вроде магии: люди нажимают на клавиши, потом покупают квартиру.

В какой-то момент решила перестать смотреть на это со стороны и попробовать сама.

Что будет в этом дневнике:

• самые глупые ошибки, которые только можно сделать;

• мемы про Python;

• разборы того, что наконец удалось понять.

Пока мои достижения выглядят так:

1. установила Python;

2. установила VS Code;

3. случайно открыла терминал;

4. испугалась.

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

Если кому-то будет смешно - отлично.

Если кому-то пригодится мой опыт - ещё лучше.

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

День 1 начинается. Пожелайте удачи. Кажется, дальше будут отступы.

P.S. Если через неделю увидите пост "Перешла разводить суккуленты", значит Python оказался сильнее.

1. Вытаскивать суть (AI Digest): Бот сам заходит по ссылке (даже если там пейволл или сайт перегружен скриптами), выкачивает чистый текст, анализирует его с помощью ИИ и выдает мне сжатую суть в виде лаконичного дайджеста. Чтение статьи на 15 минут теперь занимает 30 секунд.

2. Умный слайдер: Если у вас мало времени, бот генерирует короткие слайды-выжимки по ключевым темам.

3. Карманный подкаст (Аудиофичи): Моя любимая фишка. Бот умеет озвучивать дайджесты голосом. Я просто нажимаю кнопку, вставляю наушники и слушаю выжимку утренних новостей, пока варю кофе или иду на прогулку.

4. Никакой рекламы и мусора: Никаких баннеров, всплывающих окон и кликбейтов.

Как это устроено внутри?

Архитектура довольно простая, но отказоустойчивая. Бот написан на Python (библиотека Aiogram 3). В качестве базы данных используется PostgreSQL для хранения пользователей и подписок, а быстрый кэш и стейты (FSM) крутятся на Redis. Парсингом и очисткой страниц от мусора занимается кастомный инстанс Mercury Parser API, а суммаризацией и генерацией аудио — легковесные и быстрые ИИ-модели.

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

Для чего я это пишу?

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

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

Ссылка на бота: @RSS_READER_AI_Bot

Берегите свой фокус и не позволяйте алгоритмам решать за вас, что сегодня читать!

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

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

В связи со всем вышеперечисленным выбор наш пал на аппаратные ключи, которые в клиентский комп вставляются в USB-порт и без которых наша защищаемая CAD-система превращается в тыкву.

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

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

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

Это очень не просто - выбрать такие чистые (в функциональном смысле). компактные (в донгле не так много места), не критичные к скорости (ява-машина в ключике не впечатляла скоростью, а всё ещё и через USB2.0 работало... если не 1.1, не помню уже), нетривиальные функции, которые нельзя было бы повторить так просто в эмуляторе ключа.

Да, можно было так же наговнякать как в исходном посте, вернуть true и проверять потом, но такие ключи - просто деньги на ветер.

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

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

И да, надо понимать, что любая просто быстро и наивно реализованная защита легко и дёшево обходится. Главное, чтобы это было экономически выгодно, а за взломом дело не встанет.

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

И вот тут я расскажу ещё про один лайфхак. Защита должна быть многослойная и вероятностная.

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

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

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

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

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

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

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

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

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

Если непонятно что-то объяснил - спрашивайте. Мне казалось я умею объяснять сложные вещи простыми словами, особенно если сам понимаю эти сложные вещи. Но и на старуху, как говорится...