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

Этот материал посвящён взлому промптов Notion AI, семи методикам реверс‑инжиниринга промптов и рассказу о том, почему все ошибаются в своих мнениях о промпт‑инъекциях (prompt injection).

Вчера я получил доступ к публичной альфа‑версии Notion AI. У меня ушло 2 часа на то, чтобы, пользуясь промпт‑инъекциями, раздобыть полные тексты внутренних промптов, применяемых для реализации каждой из возможностей Notion AI.

Сегодня я публикую тексты этих промптов, но делаю это не потому, что я — человек безответственный; я отстаиваю точку зрения, в соответствии с которой в этом нет ничего страшного. И я воздаю должное команде Notion, которая так хорошо интегрировала возможности искусственного интеллекта в свой продукт.

Мне, кроме того, пришлось разработать и использовать кое‑какие новые техники приблизительного определения исходных текстов промптов. Я подумал, что было бы интересно представить их вам — моим замечательным читателям.

Прошло уже достаточно времени с момента релиза Python версии 3.10. Самым главным и самым ожидаемым было введение оператора match/case (он же pattern matching). 

Однако далеко не всем разработчикам из комьюнити зашел данный оператор. Свидетельствуют этому даже комментарии под статьями на хабре (статья 1, статья 2), которые были посвящены match/case.

На мой взгляд, новый оператор упрощает жизнь разработчикам, принимая на себя работу с проверкой типов данных или принадлежность определенному классу. Но, как мы все знаем, зачастую за крутые фичи, введенные в язык, программисту приходится платить. В данной статье я хотел бы осветить тему производительности оператора match/case и сравнить его с обычным if/else.

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

Разбираемся с «чёрными ящиками» и c тем, какими они бывают сегодня

• Вы работаете со сторонним ПО, разработчики которого просто не раскрывают код.
• Вы взаимодействуете с API, внутренняя логика которого абстрагирована.
• У вас нет необходимых полномочий для доступа к Git-репозиторию.
• Даже система с полным доступом может де-факто стать «чёрным ящиком» из-за своей сложности.
• Сотрудник, обладавший всеми ключами и знаниями, внезапно уволился/пропал/умер.
• Легаси-система состоит из .dll, которая «всегда работала» на сервере, и не была подключена к системе контроля версий. Чтобы просто посмотреть на код, её нужно декомпилировать, если это возможно, конечно.

var_dump($variable);
die();

console.log(data);

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

По роду своей деятельности (Windows Kernel) мне регулярно приходится разбирать дампы BSOD'ов. Не единичны случаи, когда у конечного пользователя успешно пишутся только Mini-дампы, в которых сохраняется только значение регистров процессора и стек падения. А другого средства отладки клиентской машины просто нет. Но что делать, если в стеке нет нашего драйвера, а заказчик настаивает, что падения начались после установки продукта и закончились после отключения драйвера этого продукта? В моем случае хорошим решением оказалось ведение небольшого журнала последних событий в циклическом буфере. Осталось только сохранить этот циклический буфер в дампе.

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

(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8

• 2,2 млрд. — Количество пользователей электронной почты по всему миру
• 144 млрд.- Объем отправляемых электронных писем ежедневно во всем мире
• 4,3 млрд.- Количество почтовых клиентов во всем мире

Зачем нужна эта статья?

… Супер-простой SMTP-сервер, который перехватывает любое отправленное сообщение и выводит его в веб-интерфейсе. Запустите mailcatcher, в настройках вашего приложения укажите smtp://127.0.0.1:1025 вместо SMTP-сервера по умолчанию, и затем просматривайте почту, которая была отправлена по адресу 127.0.0.1:1080

Одно время  на прогулках по блошиным рынкам я увлеченно высматривал винтажные музыкальные инструменты, особенно синтезаторы 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), возникающими сразу в нескольких операторах. Выглядит это примерно так:

"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.

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

Уровни логирования (error, warning, information, ...) здесь помогают мало. Обычно для приложения выставляется некий целевой уровень (например, information). Это означает, что все записи с уровнем выше или равным данному попадают в логи, а менее значимые выбрасываются. Но в тот момент, когда происходит ошибка, для нас наибольший интерес представляют именно записи debug-уровня, которые обычно и выбрасываются. Хорошо, если ошибка встречается довольно часто. В это случае можно временно опустить целевой уровень логирования системы, собрать информацию об ошибке, а потом вернуть уровень назад. Таким образом объём собираемых логов возрастёт только временно. Если же ошибка встречается достаточно редко, такой подход хоть и возможен, но не очень удобен, поскольку приводит к значительному росту объёма логов.

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

Введение

Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.

Чему нас учат в вузах

Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.