Когда захотелось ну очень тёмную тему 🌘

Отсюда

Troubleshooting. Метод деления пополам

Продолжаю серию постов по траблшутингу. Сегодня поговорим про локализацию проблемы методом деления пополам.

Метод деления пополам используется, например, в электротехнике ⚡️ для поиска обрыва в цепи. Для этого участок цепи визуально разбивается пополам и каждая половина проверяется на предмет наличия тока. Та половина, в которой тока нет, считается содержащей обрыв. Она в свою очередь снова разбивается пополам и половинки снова проверяются. Так продолжается до тех пор, пока мы не придём к проблемному месту.
А мы придём к нему в общем случае быстрее, чем если бы последовательно проверяли цепь по маленьким "кусочкам".

Вот такой итерационный метод можно использовать и при отладке программ.

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

1️⃣ Для начала выбираем большой участок программы от ее старта до места проявления ошибки. Мы уверены, что в начале выполнения программы наши данные корректные.

2️⃣ Теперь визуально делим выбранный участок программы пополам и проверяем корректность данных в месте разделения. Если данные корректные, то выбираем следующий по ходу участок программы. Если данные не корректные, то - предыдущий.

3️⃣ Продолжаем пункт 2 до тех пор, пока не "спустимся" к источнику проблемы.

Кстати, таким же методом можно искать ошибки не только по процессу выполнения программы, но и по истории коммитов.

Для этого нужно знать коммит, на котором проблемы еще не было, и коммит, на котором проблема была обнаружена. Тогда путем деления истории коммитов пополам можно быстро найти коммит, который занёс в код ошибку. В git, например, этот метод реализуется командой git bisect. Почитайте, если ещё не слышали.

#Troubleshooting

Zip-бомба и Qt Network

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

Давайте проверим, что случится, если такой архив получит QNetworkAccessManager из модуля Qt Network. Есть ли там какая-то защита?

QNetworkAccessManager умеет работать с HTTP-запросами и ответами. И если в HTTP-заголовке ответного сообщения будет установлено поле Content-Encoding: gzip, то QNetworkAccessManager должен автоматически разархивировать полученные данные.

Так в действительности и происходит. Но в случае с zip-бомбой есть и хорошие новости. Многократно запакованный архив QNetworkAccessManager распаковывает только один раз, рекурсивной процедуры там нет. По крайней мере в Qt5. Значит такого типа zip-бомб можно не опасаться.

А вот архив с сильным сжатием ожидаемо будет распакован.

В эксперименте архив размером 1,2Мб, содержащий 1,2Гб данных, был распакован QNetworkAccessManager-ом за несколько минут с потреблением в пике до 2,4Гб оперативки. Как минимум, это может привести к фризам приложения в процессе распаковки, а при определенных условиях и к падению.

Такие пироги. Если Qt Network работает по незащищенному протоколу, то такой тип атаки можно ожидать. С защищенным протоколом (HTTPS) вероятность гораздо ниже.

Если интересно как еще проверить свою систему на прочность, читайте пост про выполнение DOS-атаки.

Антипаттерны SQL: обязательный столбец ID

У меня отношения с базами данных (БД) примерно такие же как с английским: вроде бы нормально дружим, пока не попадется что-то серьёзнее Шерлока Холмса в оригинале. В теории все понятно, но нет-нет да и выкину что-нибудь эдакое.

И в этот раз при работе со схемой БД я заметил, что по умолчанию добавляю поле "ID" в каждую таблицу 🤔
Просто потому что, без оснований. По традиции что ли...

Так себе, да?
Да. И у этого есть название.

Я пал жертвой антипаттерна "ID required", вляпавшись в два его признака:

1️⃣ Несколько таблиц в моей БД безосновательно получили поле "ID" в качестве первичного ключа, хотя у каждой из этих таблиц уже было поле, которое могло бы им стать. Тем самым появилась избыточность данных.

2️⃣ Имя "ID" очень абстрактное, ни о чем не говорящее само по себе. Гораздо лучше было использовать не "ID", а какой-нибудь условный "ENTITY_ID".

Таким образом, после удаления поля "ID" и назначения первичным ключом другого подходящего поля, замысел созданной мной сущности и ее связей никак не изменился. Что хотел, то и получил.

Из самого описания антипаттерна "ID required" мне понравилась эта фраза:

If your table contains an attribute that’s guaranteed to be unique, is non-null, and can serve to identify the row, don’t feel obligated to add a pseudokey solely for the sake of tradition.

То есть антипаттерн не говорит, что поле "ID" - это плохо, а только лишь указывает, что оно не обязательно.

📍 Karwin B - SQL antipatterns. Avoiding the pitfalls of database (2010)