Чем собирать python-приложения для поставки

На python удобно писать небольшие приложения. Путь "от идеи до модели" очень короткий. Но просто скрипт пользователю не поставишь, надо поставлять и дистрибутив python. Много мороки.

Для создания standalone-приложений на python широко используется pyinstaller. В одну команду можно получить exe-файл заданного скрипта. И все бы хорошо, если бы не антивирус. Файл, сгенерированный через pyinstaller, часто определяется как Троян. У меня, например, в VirusTotal приложение определялось как вредоносное в 20 из 72 анализаторов. Жесть. Windows Defender прибивает exe-файл сразу после генерации. А причина в том, что pyinstaller-ом часто собирают вредоносное ПО. Поэтому базы антивирусов содержат его генеративные шаблоны.

Но есть альтернатива - nuitka. Это аналогичный инструмент, но с немного другим принципом работы. Nuitka генерирует C-код и потом компилирует из него бинари. Вероятность определения как вредоносное ПО значительно снижается. В моем случае сгенерированный exe-шник пометили нежелательным всего 4 из 72 анализаторов. Приемлемый результат.

Сгенерированные дистрибутивы в nuitka и pyinstaller практически не отличаются по размеру. В то же время nuitka работает значительно дольше и требует наличия в системе C-компилятора. Но пусть уж так, чем: "У вас тут троян!"

Навигация развязок

В Санкт-Петербурге на объездной дороге проезжал сложную развязку. 2 раза проезжал и оба раза промахнулся съездом. А на таких развязках это чревато лишним десятком километров. Неприятно. Вроде бы и навигатор, и дорога перед глазами, но… мимо.

Развязка непростая: прямого направления перед глазами нет. Все направления многополосные и все поворачивают на разных уровнях. И съезда налево нет: есть движение прямо и 3 съезда направо. Мне нужен был 3-й съезд, но я благополучно уезжал на второй. Добавляла неудобства скорость. Это автомагистраль на 110 км/ч. Реагировать надо быстро.

На фоне этой проблемы появилась мысль. А почему бы навигатору не проговаривать номер съезда с развязки, как он это делает для кольца? Ну например: “Поверните на развязке направо. Третий съезд” или “Держитесь на развязке правее в третий съезд”. Съезды то я успел посчитать, я не успел понять какой из них мой. Если бы навигатор проговорил номер съезда, было бы легче.
Хотя для простых развязок, где съезда всего два (направо и налево), это скорее лишнее.

А пока самый простой вариант в таких случаях - это ориентироваться на знаки. Над съездами висят обозначения направлений. Но для этого надо хорошо запомнить маршрут и окрестности. Потому что указатель на "Дачный пр-т" мне ни о чем не говорит.

vtour - виртуальный тур на минималках

vtour - это JavaScript-библиотека для создания виртуальных туров на базе цилиндрических панорам.
Идея сделать библиотеку появилась после этой статьи на Хабре, где автор с обычным фотоаппаратом делал красивые панорамы. Просто и быстро. Но на основе Flash’а. А нам он, мягко говоря, не нужен. Надо JS.

Я взял телефон, встал в центре комнаты и сделал с рук десятка два фотографий вокруг себя. В микрософтовском ICE склеил фотографии в одну круговую панораму. В Gimp немного поправил “ступеньки” в местах склейки. Итоговую панораму натянул на цилиндр на сцене three.js и разместил в центре камеру. Буквально за пару вечеров у меня на руках был тур по квартире.

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

Возможности vtour:
- отображение цилиндрических панорам (вращение, масштабирование),
- переходы между цилиндрическими панорамами (тур),
- точки интереса в виде фото-спотов.

В проекте есть синтетическое демо для оценки функциональности, а музейный тур можно посмотреть здесь.

YouTube Analyzer 2.0

Релизнул новую версию YouTube Analyzer - анализатора поисковой выдачи YouTube. Главное изменение - возможность использовать YouTube API. Поиск через YouTube API включается автоматически при вводе ключа API в настройках приложения.

По умолчанию поиск выполняется все тем же “грепом” html, так как внедрять ключ API в приложение я не стал. Дело в квотах. Бесплатно YouTube API выделяет 10 000 единиц в сутки. Один поисковый запрос в анализаторе стоит 102 единицы. То есть в сутки доступно 98 запросов. Не знаю, много это или мало. Пока понаблюдаю статистику. Возможно в будущем зашью публичный ключик в приложение.

Помимо YouTube API добавил русский язык интерфейса, темную тему и сохранение состояния приложения в настройках. Реализация на Python/PySide6 (Qt). Так что сохраняйте репу, может пригодиться.

Конечные автоматы

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

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

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

Но какие границы применимости? Сколько можно поддержать состояний в пределах одного компонента и не сломать себе голову? Удобно ли масштабировать?

Сразу и не ответишь. Но уже предварительно можно сказать, что даже у небольшого приложения наберётся много состояний. Логика автоматов этому способствует.

Тем не менее на новом проекте я решил пощупать эту концепцию средствами Qt State Machine. Как минимум, хочу ответить на вопросы выше. Как максимум - выработать практический пример использования и потом им поделиться.

Как работать с легаси-кодом

Легаси-код - это историческая часть кода, с которой сложно работать. Почему? Потому что документации нет, авто-тестов нет, эксперта нет. Часто такое происходит? Да в общем-то да. В долгоживущих коммерческих проектах прям обязательно. Что делать?

Как только почувствовал, что твоя зона интереса уходит в легаси, нужно …не паниковать. Ну да, не всегда будет легко. Иногда своими руками приходится делать ведомым что-то неведомое.

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

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

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

Jack Franklin - Five steps for managing legacy code

Управление памятью в C++

C++ позволяет явно управлять выделенной памятью. Мощный инструмент.
И с этой мощью проще простого выстрелить себе в ногу.

Поэтому сообщество рекомендует:
1. Максимально использовать стек, а не кучу. И уж точно не выделять память динамически только “потому что я могу”.
2. Если динамическое выделение памяти необходимо, используем автоматическое управление ресурсами (RAII). То есть умные казатели, контейнеры и прочее, что позволяет нам не вызывать явно new/delete или хотя бы delete.

Кстати, про delete. Известно, что ОС при завершении программы сама удалит все, что мы забыли. Даже допустимо не подчищать память самому - так проще, да и программа будет завершаться быстрее. Наверное так. Но в С++ чистить за собой - хорошая привычка. Лучше ее придерживаться. Ведь в деструкторе может быть что-то большее, чем пустые скобки.

What is the philosophy of managing memory in C++?

Национальная безопасность

В феврале 2024 года Белый дом США выпустил отчет, в котором призвал программистов переходить на языки программирования с безопасным доступом к памяти. А если легаси и все такое, то необходимо максимально использовать memory-safe практики. На кону национальная безопасность.
Почему все так серьёзно? Потому что самые мощные эксплойты последнего времени появились на почве небезопасного управления памятью.

По версии АНБ США языки программирования Python, C#, Go, Java, Ruby, Swift и Rust считаются безопасными. Небезопасные ожидаемо C и C++, которые позволяют программисту “распускать руки” по отношению к памяти.

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

В дополнение ко всему не надо забывать про предупреждения компилятора, юнит-тесты и статические анализаторы. Тот же cppcheck умеет находить уязвимости по разным классификаторам.

…

Не думаю, что C и C++ скоро канут в Лету. Хоронят их давно и регулярно. И тем не менее проблемы языков надо принимать и работать соответствующе.

In Rust we trust? White House Office urges memory safety

Гололед

Эта зима выдалась особенно интересной на дорожные условия. Чего только не было. Но сегодня вспомним про гололед. Какие системы автомобиля тут могут помочь? Шипы - шипами, а знать о попадании на лед хотелось бы до начала проблем. Ведь лед может быть невидимым, его еще называют "черный лед".

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

В общем тема исследована, решения есть. Но их широкого применения нет. Поэтому стоит помнить кое-какие практики, которые помогут понять, что под колесами лед:
1. Смотреть на дорогу. Лёд все таки блестит.
2. Проверять покрытие тормозами. Нужно очень плавно отпустить газ и слегка поджать тормоз. Если под колесами лед, то они практически сразу заблокируются.
3. Слушать дорогу. На льду колеса шумят немного тише, чем на асфальте.
4. Наблюдать за машиной. Если на прямой дороге вдруг приходится подруливать, “ловить” машину, то скорее всего мы на льду. Ощущение чем-то похоже на движение со спущенным задним колесом.
5. Быть внимательным на мостах, на теневых участках, в крайней правой полосе на трассе и во время осадков в мороз. Дождь и мороз - суровый тандем, а правая полоса здорово полируется грузовиками.

Есть что добавить?

#Авто

Поиск информации по проекту

Согласно опросу на Stack Overflow, четверть разработчиков тратят более часа в день на поиск информации, необходимой для работы. Много? Ну, it depends, как говорится. В исследовательских проектах поиск информации вообще является непосредственной работой. Но сейчас немного не об этом.

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

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

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

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

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

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

Who owns this tool? A software component catalog to help devs find answers

Без труда...

С детства мы знаем, что “без труда не вытащишь и рыбку из пруда” и “если долго мучиться, то что-нибудь получится”. Шутки конечно, но суть понятна - работай.

На этом фоне вспомнил еще несколько изречений, которые мне в разное время попались.

“Увы, наскоком загадки мироздания не решаются”. - Сергей Лукьяненко, “Спектр”.

“Где, когда, какой великий выбирал путь, чтобы протоптанней и легше?” - Владимир Маяковский, “Сергею Есенину”.

И самое любимое:

“Дрянь, говорю…, вдохновение — дрянь! Порыв к работе важнее. На одном вдохновении далеко не ускачешь. Гений — это лишь талант, который работает, работает, работает..., пока не сдохнет. Разве не так, Ванюшка? Корпеть надо — тогда получится”. - Валентин Пикуль, “Полет и капризы гения”.

Что еще знаете?

#КнижнаяПолка

Функция, метод или процедура

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

Так функция всегда возвращает значение. А если функция не возвращает значение, то это - процедура. Функцию, принадлежащую классу или объекту, называют методом.

Method vs Function vs Procedure
#Словарь

“Напишем и исправим”

Небольшая заметка про решение задач "в лоб".

Почти 75% коллективов разработчиков начинают работу, налетая на глыбу и пытаясь подвинуть ее при помощи грубой силы. Такой подход – сразу хвататься за написание программ, не позаботившись о планировании и проектировании – получил наименование «напишем и исправим».

Разработка по принципу «напишем и исправим» неэффективна во всех проектах, за исключением самых мелких.

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

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

Макконнелл С - Профессиональная разработка ПО (глава 2)

Переполнение буфера

В C++ записать данные мимо буфера - раз плюнуть. Называется это buffer overflow (BO). Вот пример как это происходит в стековой памяти.

#include <stdio.h>

int main()
{
    char a[4] = "aaa";
    int b = 23;
    char c[4] = "ccc"; 
    
    printf( "a = %s\n", a );
    printf( "b = %d\n", b );
    printf( "c = %s\n", c );
    
    printf( "Assign 'c' with overflow\n" );
    sprintf( c, "%d", 1234567089 );
    
    printf( "a = %s\n", a );
    printf( "b = %d\n", b );
    printf( "c = %s\n", c );
    
    return 0;
}

Вывод программы будет такой:

a = aaa
b = 23
c = ccc
Assign 'c' with overflow
a = 89
b = 808924725
c = 1234567089

После записи избыточных данных в буфер c, оказываются поврежденными данные в переменных a и b, находящихся ниже по стеку.

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

Кстати, на собеседованиях это популярный вопрос.

YouTube Analyzer 3.0

Выпустили новую версию YouTube Analyzer - анализатора поисковой выдачи YouTube.

Добавлено:
- Боковая панель с превью и тегами выбранного видео.
- Экспорт данных в таблицу HTML.

YouTube Analyzer - классическое desktop-приложение, написанное на Python/PySide(Qt). Его решения можно использовать как шаблон для своих приложений.

Когда заменять легаси на новую технологию?

Понятно, что переписывать легаси “только потому что” не нужно. Надо понимать, что мы хотим получить от новой технологии и какие преследуем цели.
А цели и их предпосылки могут быть такие:

1. Снижение стоимости изменений. Когда внесение изменений обходится дорого или легаси-система начинает диктовать объем доработок.

2. Улучшение бизнес-процессов. Когда ограничения легаси-системы не позволяют улучшить продуктовые бизнес-процессы.

3. Отказ от устаревшей системы. Когда сложно и дорого поддерживать старый софт или железо.

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

5. Приоритетные новые технологии. Когда новая технология лучше соответствует потребностям бизнеса сейчас и в будущем.

Patterns of Legacy Displacement

Внедрение DLL в EXE

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

Написал этот вопрос в комментарии автору статьи и... вопрос не прошел модерацию😁 Потёрли.

Полазил по сети, может кто-то так делал. И да, конечно делал. Мотивов, в общем-то, два:

1. "Кидаю дружбану exe-шник, а он у него не запускается из-за отсутствия dll. Как встроить эти dll в exe-шник?". Это самый популярный мотив. Оставим его сразу в покое.

2. "Требования/коллеги/заказчик не допускают, чтобы конкретная dll была видна пользователю. Как спрятать ее в exe-шник?". В этом мотиве веса больше. Но это скорее "костыль", прикрывающий проблемы реализации.

Поэтому вопрос остается открытым.
Может ли внедрение DLL в EXE быть действительно полезным на практике?

Есть идеи?

Управление памятью: “парашют”

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

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

Макконнелл С - Совершенный код (глава 13.2)

"Голос науки"

Зарегистрировался на платформе “Голос науки”. Это социальная сеть для российских ученых.
Как раз для меня 😉
https://golos-nauki.ru/u/2495217

Говорят, эта платформа должна импортозаместить ResearchGate. Ну, посмотрим-посмотрим. Понаблюдаю в режиме read only. Пока.

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

Тем не менее, система в бетке. Все впереди.

Путаница в интерфейсах (часть 2)

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

Моя самая больная троица: git restore / git revert / git reset.
Ну когда бы не вводил одну из команд, обязательно перепутаю! Как проклятие. Осложняется еще и тем, что используешь их не каждый день. Не получается запомнить.

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

Композиция или агрегация

В ООП оба термина описывают отношение между классами как “часть-целое”. Но у каждого своя оговорочка.

Агрегация - это отношение по ссылке, когда оба объекта могут существовать сами по себе, независимо.

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

Новичкам это надо запомнить. Как минимум для собеса. Как максимум, чтобы не впадать в ступор после фразы “давай здесь наследование композицией заменим”.

В википедии в принципе норм примеры, можно почитать поподробней.

P.S.
Получается уже целая серия постов с терминами - студенты сами подсказывают примеры😉
Хорошая кладовочка для быстрых ответов)

#Словарь