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.
Получается уже целая серия постов с терминами - студенты сами подсказывают примеры😉
Хорошая кладовочка для быстрых ответов)

#Словарь

Иногда я отхожу от основной темы канала. Бывает редко, но бывает. Я писал и про технику, и про природу, и про людей.

Чем шире наш кругозор, тем лучше. Особенно в тех сферах деятельности, где есть место творчеству и изобретательству. А в разработке ПО этого хоть отбавляй.

В общем… киты.