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

Отладка *
Поиск и устранение ошибок в коде
Реверс-инжиниринг промптов for fun and (no) profit

Этот материал посвящён взлому промптов Notion AI, семи методикам реверс‑инжиниринга промптов и рассказу о том, почему все ошибаются в своих мнениях о промпт‑инъекциях (prompt injection).
Вчера я получил доступ к публичной альфа‑версии Notion AI. У меня ушло 2 часа на то, чтобы, пользуясь промпт‑инъекциями, раздобыть полные тексты внутренних промптов, применяемых для реализации каждой из возможностей Notion AI.
Сегодня я публикую тексты этих промптов, но делаю это не потому, что я — человек безответственный; я отстаиваю точку зрения, в соответствии с которой в этом нет ничего страшного. И я воздаю должное команде Notion, которая так хорошо интегрировала возможности искусственного интеллекта в свой продукт.
Мне, кроме того, пришлось разработать и использовать кое‑какие новые техники приблизительного определения исходных текстов промптов. Я подумал, что было бы интересно представить их вам — моим замечательным читателям.
Match/case vs If/else. Сравниванием скорость работы операторов в Python 3.10

Прошло уже достаточно времени с момента релиза Python версии 3.10. Самым главным и самым ожидаемым было введение оператора match/case (он же pattern matching).
Однако далеко не всем разработчикам из комьюнити зашел данный оператор. Свидетельствуют этому даже комментарии под статьями на хабре (статья 1, статья 2), которые были посвящены match/case.
На мой взгляд, новый оператор упрощает жизнь разработчикам, принимая на себя работу с проверкой типов данных или принадлежность определенному классу. Но, как мы все знаем, зачастую за крутые фичи, введенные в язык, программисту приходится платить. В данной статье я хотел бы осветить тему производительности оператора match/case и сравнить его с обычным if/else.
Когда нужна телеметрия: интегрируем в проект библиотеку логирования uP7

Зачастую разработчику, или даже пользователю, требуется посмотреть, что происходит внутри устройства. Обычно в таких ситуациях используют либо текстовой вывод в терминал (через голый UART или самописный протокол гарантированной доставки), либо пишут свои собственные системы логирования. Однако, всегда ли оправдан такой подход? Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких - библиотеку логирования uP7.
Как отладить программу, к которой у тебя нет доступа

Фото: Intricate Explorer, Unsplash
Сегодня я вспомнил один из любимых «программистских мифов», который вполне может быть городской легендой, и свою собственную версию «чёрного ящика», который требовал отладки.
Городская легенда повествует о радиоактивных железнодорожных вагонах из Украины, вызывавших баги в компьютерной системе, прочитать её можно здесь.
Разбираемся с «чёрными ящиками» и c тем, какими они бывают сегодня
«Чёрный ящик» — это популярная концепция программирования, предполагающая, что мы находимся снаружи системы или компонента, не имея прямого доступа к коду. Это может быть вызвано различными факторами:
- Вы работаете со сторонним ПО, разработчики которого просто не раскрывают код.
- Вы взаимодействуете с API, внутренняя логика которого абстрагирована.
- У вас нет необходимых полномочий для доступа к Git-репозиторию.
- Даже система с полным доступом может де-факто стать «чёрным ящиком» из-за своей сложности.
- Сотрудник, обладавший всеми ключами и знаниями, внезапно уволился/пропал/умер.
- Легаси-система состоит из .dll, которая «всегда работала» на сервере, и не была подключена к системе контроля версий. Чтобы просто посмотреть на код, её нужно декомпилировать, если это возможно, конечно.
Руководство по обработке ошибок в JavaScript

Выше мы говорили об ошибках, которые люди совершают в обычной жизни. Ошибки в программировании — это нечто иное. Сообщения об ошибках помогают нам улучшать код, они позволяют сообщать пользователям наших проектов о том, что что-то пошло не так, и, возможно, рассказывают пользователям о том, как нужно вести себя для того, чтобы ошибок больше не возникало.
Как подружить PHPstorm, xDebug и удаленные ветки, собранные через Docker? Слишком просто…
Еще год назад мой процесс отладки кода в PHP заключался в двух строчках:
var_dump($variable);
die();
Периодически, конечно, приходилось использовать более «сложные» конструкции:
console.log(data);
echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();
Нет, что вы! Я знал — в наше время не подобает культурному программисту заниматься этим
Но, честно говоря, я всегда боялся того, что не понимаю. В том числе и
Если Вы так же, как и я, испытываете трудности с настройкой разных штук, добро пожаловать под кат, я расскажу о своем опыте настройки окружения отладки с такими страшными словами, как Docker, xDebug, CI.
Общая картина модульного тестирования

Это не руководство, какие символы нужно ввести в редакторе кода, чтобы получились модульные тесты. Это — пища для ума, которую необходимо употребить до того, как предпринимать упомянутые действия.
Тема модульного тестирования не так проста, как может показаться. Многие из нас, разработчиков, приходят в модульное тестирование под давлением клиентов, сотрудников, коллег, своих кумиров и так далее. Мы быстро понимаем его ценность, и, закончив технические приготовления, забываем об общей картине, если вообще когда-либо её понимали. В этой статье я вкратце расскажу о том, чем является и чем не является модульное тестирование как в целом, так и в PHP, а заодно опишу, какое место занимает модульное тестирование в сфере QA.
Мониторинг JavaScript-ошибок с помощью window.onerror
window.onerror
. Это — особое событие браузера, которое вызывается при появлении неперехваченных ошибок. Здесь мы поговорим о том, как перехватывать ошибки с помощью обработчика события onerror
, и о том, как отправлять сведения о них на сервер разработчика веб-сайта. Этот обработчик можно использовать в качестве основы собственной системы сбора и анализа информации об ошибках. Кроме того, он является одним из важнейших механизмов, применяемых в библиотеках, ориентированных на работу с ошибками, таких, как raven-js.
Собственные данные в системном дампе падения Windows
По роду своей деятельности (Windows Kernel) мне регулярно приходится разбирать дампы BSOD'ов. Не единичны случаи, когда у конечного пользователя успешно пишутся только Mini-дампы, в которых сохраняется только значение регистров процессора и стек падения. А другого средства отладки клиентской машины просто нет. Но что делать, если в стеке нет нашего драйвера, а заказчик настаивает, что падения начались после установки продукта и закончились после отключения драйвера этого продукта? В моем случае хорошим решением оказалось ведение небольшого журнала последних событий в циклическом буфере. Осталось только сохранить этот циклический буфер в дампе.
Под катом я расскажу, как из своего драйвера добавить в дамп данные. А затем извлечь их, используя pykd.
Отладка React-приложений в VS Code

Прошли те дни, когда мне, в процессе разработки, приходилось тратить время, переключаясь между терминалом, браузером и редактором. Теперь всё делается иначе — быстрее и удобнее. Сегодня я расскажу об оптимизации повседневных дел React-разработчика. А именно, речь пойдёт о том, как связать Visual Studio Code и Google Chrome. Это даст возможность отлаживать браузерный код в редакторе.

Средства отладки VS Code и jest от Facebook
Jaeger Opentracing и Microservices в реальном проекте на PHP и Golang

Украшаем жизнь с помощью gdb PrettyPrinting API
(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8
Я подумал «а фигли?». И все заверте…
Ближайшие события
Отладка электронной почты при помощи MailCatcher

- 2,2 млрд. — Количество пользователей электронной почты по всему миру
- 144 млрд.- Объем отправляемых электронных писем ежедневно во всем мире
- 4,3 млрд.- Количество почтовых клиентов во всем мире
Потрясающе!
Зачем нужна эта статья?
По одной простой причине, с которой мы все так или иначе сталкиваемся. Необходимо тестировать функционал как можно ближе к реальному применению, и любая ошибка может привести к тому, что наши клиенты получат тестовые письма, и это будет печально.
Я уверен, вы знаете о чем я говорю. Думая, что перевели приложение в режим отладки, вы запускаете тест, который отправляет письма из вашего приложения. Вы думаете что никто кроме вас не увидит эти письма.
Тесты проходят, вы хвалите себя и продолжаете работу. Но спустя некоторые время вы получаете звонок от своего заказчика. Он жалуется, что его клиенты получили странные. Он расстроен и хочет получит ответ.
Было такое? Не хочется, чтобы повторилось? Есть решение — MailCatcher. Если вы не слышали о нем то вкратце:
… Супер-простой SMTP-сервер, который перехватывает любое отправленное сообщение и выводит его в веб-интерфейсе. Запустите mailcatcher, в настройках вашего приложения укажитеsmtp://127.0.0.1:1025
вместо SMTP-сервера по умолчанию, и затем просматривайте почту, которая была отправлена по адресу127.0.0.1:1080
Неплохо звучит, верно? Независимо от того, устали ли вы, перегружены работой, есть ли новенький в команде или еще какая беда — MailCatcher гарантирует, что электронная почта останется в пределах вашей сети, или даже вашей виртуальной машины.
Сейчас я хочу показать вам, как настроить, запустить и использовать MailCatcher.
Удаленная отладка веб-приложений в облаке с Visual Studio 2013

С выходом инструментов Windows Azure SDK 2.2 разработчики облачных приложений и сервисов Windows Azure получили отличное расширение возможностей Visual Studio 2013, которое позволяет отлаживать код удаленно прямо из облака. Удаленная отладка приложений доступна как для ролей облачных сервисов (Cloud Services) так и веб-сайтов (Windows Azure Web Sites).
Рассмотрим как разработчик может использовать новые возможности удаленной отладки для разработки приложений Windows Azure. Для начала нам потребуется Visual Studio 2013 RTM с установленным пакетом Windows Azure SDK for .NET 2.2. Visual Studio 2013 уже должна иметь привязку к подписке Windows Azure.
Восстановление раритетного аналогового синтезатора Alpha Juno-1 фирмы Roland

Одно время на прогулках по блошиным рынкам я увлеченно высматривал винтажные музыкальные инструменты, особенно синтезаторы 70x-80x годов. Я нахожу их звуки очень красочными и разнообразными, а так же эти устройства интересны с точки зрения схемотехники.
И вот однажды по счастливой случайности и благодаря алгоритму поиска на основе AI на одном из самых популярных интернет-сервисов для купли-продажи подержанных вещей, который предложил мне объявление по моим интересам.
И это оказалась не «пиликалка» с пластиковым звуком и не кондовый электроорган, - а очень даже продвинутый для середины 80ых и актуальный по сей день аналоговый полифонический синтезатор с цифровым управлением, выпущенный компанией Roland.
После приобретения музыкальный инструмент не подавал ни каких признаков жизни кроме подсветки дисплея. Вскрытие и сверка со схемой из документации показали то, что хоть разработчики и использовали Poka Yoke для предотвращения неправильного подключения межплатных кабелей, но или не досмотрели или ассортимента не хватило и установили на главной плате два разъёма с одинаковым количеством контактов и невнимательный настройщик который обслуживал синтезатор перепутал местами те единственные два кабеля в которых можно было ошибиться. В таком вот состоянии инструмент мне и достался. Уcтранив ошибку сначала я очень обрадовался, - основные функции заработали, но к сожалению вышли из строя два входа микросхемы IC7 “Gate Array“, которая выполняет роль IO интерфейса для CPU, в частности для функций клавиатуры. Из Рис. 1 и Рис. 3-4 видно как происходит обработка нажатия клавиш.
Опыт отладки хитрой утечки прямой памяти

Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:
Flax Engine. Знакомство с игровым движком и анализ его исходного кода

"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.
Проблема объёма логов
Когда на нашей рабочей системе происходит какая-либо ошибка, нам хочется, чтобы логи содержали всю необходимую информацию о том, из-за чего она произошла. На достаточно сложных системах это приводит к сбору большого количества данных: какие этапы обработки были выполнены, с какими аргументами вызывались те или иные методы, что вернули запросы к внешним системам и т. д. Проблема заключается в том, что эту информацию нам приходится собирать даже в случае, если никакой ошибки не произошло. А это приводит к росту объёма наших логов, за который нам приходится платить деньги.
Уровни логирования (error, warning, information, ...) здесь помогают мало. Обычно для приложения выставляется некий целевой уровень (например, information). Это означает, что все записи с уровнем выше или равным данному попадают в логи, а менее значимые выбрасываются. Но в тот момент, когда происходит ошибка, для нас наибольший интерес представляют именно записи debug-уровня, которые обычно и выбрасываются. Хорошо, если ошибка встречается довольно часто. В это случае можно временно опустить целевой уровень логирования системы, собрать информацию об ошибке, а потом вернуть уровень назад. Таким образом объём собираемых логов возрастёт только временно. Если же ошибка встречается достаточно редко, такой подход хоть и возможен, но не очень удобен, поскольку приводит к значительному росту объёма логов.
Можно ли как-то улучшить сложившуюся ситуацию? Я думаю, что можно. Сразу оговорюсь, что в этой статье я предлагаю не готовое решение, а скорее пожелание к существующим системам логирования, поскольку реализация этого подхода по-видимому потребует внесения изменений в их исходный код.
Никто никогда не учит писать качественный софт

Введение
Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.
Чему нас учат в вузах
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.
Вклад авторов
acc0unt 759.0NikitaTrophimov 541.0ru_vds 491.6tangro 427.6m1rko 386.4datacompboy 351.0AloneCoder 297.2Vadimatorikda 282.0