Troubleshooting. Упрощение задачи

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

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

Вот тут то и надо задуматься о снижении сложности задачи.

Как снижать?

Нужно взять каждую гипотезу и проверить ее в минимальной простой программе. Словно в лаборатории.

🔽 Рассмотрим пример 🔽

Недавно я решал проблему с нерабочими горячими клавишами на панели инструментов в Qt. При анализе бага появилось несколько гипотез.

Первая гипотеза: проблема со стандартными кнопками QAction в самой Qt.
Для проверки гипотезы упрощаю задачу: делаю небольшую программу с единственной панелью инструментов. ➡️ В этой программе гипотеза не подтвердилась - все работало как надо.

Вторая гипотеза: проблема при переходе в режим полного экрана. ➡️ Дорабатываю свою небольшую программу - гипотеза снова не подтверждается.

Третья гипотеза: проблема при нестандартных масштабах экрана. ➡️ Проверяю в небольшой программе - опять мимо.

Четвертая гипотеза: проблема с кнопками QWidgetAction в самой Qt. ➡️ Проверяю, и, наконец-то, вот оно! Поймал!

Дошел бы я до этого в основной программе? Конечно дошел бы. Вопрос времени.

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

—

А в прошлый раз в рубрике #Troubleshooting мы разбирали логирование. Вспоминайте, кто забыл.

Нейрокейс

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

В этом примере с траблшутингом я именно так и делал. Промпт в пару предложений и приложение готово.

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

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

Например, за последний год поработал в следующих стеках:

1. C++ / Qt / OpenCasCade / CMake / qmake (desktop)
2. C / C++ / shell / Makefile (embeded)
3. Python / PySide (desktop, tests automation)
4. PHP / Symphony / Doctrine / Apache / nginx (web services)
5. JavaScript / HTML / CSS (static web app)

А у вас как? ⤵️

🎓 Июнь - время защит в учебных заведениях.

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

Поэтому нечего мне вам посоветовать 🤭

А у вас случались факапы на презентациях?

😁 - ага
👍 - нет, повезло
🤷‍♂️ - не выступал

Остаться в живых... после увольнения

Немного необычный пост. Эта информация, наверное, не пригодится ни мне, ни вам. Но будем знать 🙂

Дочитал недавно книгу Беккера "Дар страха". Это одна из тех, которые про выживание.
Информации там много, но остановимся на увольнении.

Увольнение сопровождается стрессом. Стрессом для обеих сторон. Хорошо, когда работник увольняется сам, а работодатель не против.
Но если есть конфликт?

Мне случалось увольняться, когда работодатель не хотел отпускать, и увольнять, когда сотрудник не хотел уходить. И это точно не то, что хотелось бы повторять.

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

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

Вот выжимка:

- Увольнять сразу, не растягивать процесс увольнения (испытательным сроком, например).

- Увольнять в конце дня и в конце недели, чтобы человек пошел домой как обычно, а не оказался дома в непривычное для себя время.

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

- Говорить о будущем, не говорить о прошлом.

- Лучше, чтобы увольнял не прямой начальник, а кто-то повыше.

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

- Не брать на увольнение охрану, полицию и т.п.

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

А у меня всё, и так вас утомил 😉

—

📍 Гэвин де Беккер - Дар страха. Как распознавать опасность и правильно на нее реагировать

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

Вместо latex - typst

Да и вместо markdown, чего уж там! 😅

Начал на выходных собирать руководство пользователя для нового релиза YouTube Analyzer. Раньше делал всё тупо в Google Docs. Большего и не нужно было. Но проект развивается и стало скучно в очередной раз собирать юзер-гайд в гуглодоках.

Рассматривал изначально только latex и markdown. С ними в основном и работал. Но где-то у кого-то услышал про typst и... мне понравилось)

Действительно, typst - это что-то между latex и markdown. Не очень сложно, но и не очень просто. Можно работать через плагин в VS Code. Превью шустро генерируется на ходу, различий по скорости с превью markdown не заметил. Но, справедливости ради, документ у меня пока маленький, десятка два страниц.

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

А вы где свою документацию пишете?

—

📍 Typst: Compose thesespapers faster

Баллы на ЕГЭ

Видел в сети посты от школьников, расстраивающихся своими результатами ЕГЭ. Основной посыл:
"Я писал пробники на 80+ баллов, а в итоге вытянул только на 75. Жуть какой сложный экзамен".

И с одной стороны да, для поступления каждый балл на счету. Но с другой стороны, отклонение по баллам не такое уж и большое. Около 10%.

Сейчас объясню ⤵️

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

Из личного опыта. Заезды на дорожной машине очень стабильные. На 3 боевых круга разброс бывает в пределах 1%. А вот если взять картинг, то там "болтанка" времени круга увеличивается до 5% и выше. Дорожная машина мягче и дает больше шансов исправить ошибку. А картинг жёсткий. Из-за этого потеря управления происходит резко и развивается стремительно.

И вот представьте, что попытки в практически не меняющихся условиях на треке дают разброс результата до 5%. Что же говорить про ЕГЭ, где каждая попытка - это большое количество новых условий, влияющих на результат?

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

Поэтому на мой взгляд, писать пробники на 85, а потом реальный экзамен сдать на 75 - это ок. Дай этому же человеку еще пару попыток и он точно выскочит за 80 баллов)

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

—

Помню, я в свое время как писал пробники ЕГЭ середнячком, так и экзамены сдал. Без потрясений.

Сегодня у нас тест по истории!

Целых 4 вопроса подряд ⤵️

🔼 Разнёс варианты ответов как можно дальше во времени, чтобы легче было отвечать навскидку.

Как справились?

🔥 - 100% успех
👍 - частичный успех
🤷‍♂️ - всё мимо