Привет, Хабр! Меня зовут Роман Вернин, я разработчик систем на кристалле в компании Аквариус. Вместе с коллегами мы разрабатываем микросхемы ASIC. В этой статье я хотел бы поделиться опытом, как можно использовать отладочное средство ПЛИС от фирмы Intel для тестирования, настройки или исследования устройств и стендовых систем.
int safeDiv(int a, int b) {
if (b == 0)
throw Div0(); // Исключения передаются особым образом
return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}(res, err), а Rust возвращает Result<T, E> — тип-сумму результата и ошибки.
Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:
Разбирался я в низкоуровневой работе камер iPhone, и дошёл до FaceID — системы распознавания лиц, используемой Apple для разблокировки смартфона. И наткнулся внутри на интересную вещь: чип, единственное предназначение которого в том, чтобы вывести из строя FaceID. Навсегда.
О том, как в iPhone вообще работает FaceID, где там этот чип стоит, что именно он делает, зачем его сделали таким злым, и как в ремонте справляются с этой напастью — под катом!
Мой провайдер помимо замедления (читай полная блокировка) YouTube так-же стали блокировать соединения с моими рабочими VPN. Работодатель не очень любит, когда на встречах на вопрос о прогрессе, я неделю отвечаю, что у меня не работает VPN! Своими действиями, мой провайдер сам меня подтолкнул к поиску обходных путей.
Сразу скажу, обходной путь придумал не сам, мне его подсказал автор проекта zapret, а точнее его комментарий, более того, я использую его проект, чтоб смотреть нормально YouTube. Спасибо огромное!
Добавлю, я использую nftables и nfqws, если этот вариант работает у меня — это не значит, что оно заработает и у вас! Возможно, вам придётся изменить некоторые параметры.
DispatchQueue.main.async, когда видели отчёт о сбое.
Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:
«Возьмём для примера этот код в локальной области видимости функции:
int a;
a = 5;
Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".
Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.
Можете ли вы сказать, какая строка считается инициализацией?»
Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.
Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.
Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»
В этом тексте вы узнаете, что общего между I2S трансивером и оладьями.
Да... Именно так. А также зачем программисту микроконтроллеров конвейеры и цифровые фильтры.
В тексте изложено про то, как источать звук при помощи I2S + DMA.
"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.
Одним из ключевых аспектов успешной разработки является эффективная отладка кода.
Статья посвящена настройке и использованию PhpStorm, Xdebug и Docker для отладки PHP-скриптов в Docker-контейнере. Статья предлагает актуальную информацию (на момент написания) и оформлена в виде подробнейшего пошагового туториала. Информация действительна для ОС Windows. В других ОС возможны варианты.
Цель статьи — не просто создать пошаговой конспект настроек, а объяснить, как всё это взаимодействует. Это поможет избежать затруднений при изменении интерфейса IDE в будущем. Возможно, статья выглядит слишком педантичной. Но гуру всегда смогут прочесть её по диагонали, зато новички в этой теме найдут для себя много полезного.
502 Bad Gateway — загадки, которую предстояло разрешить.
В современном мире, где обучение становится все более сложным, а тесты — настоящим испытанием для студентов и учеников, а также для начинающих специалистов, которые работают в компаниях, где сильно развито грейдирование, мы постоянно ищем эффективные способы облегчить процесс получения знаний. Специально для вас я разбираю мощный плагин для браузера, который использует возможности GPT для решения тестов на любые темы. Этот не инновационный инструмент, но таких примеров разбора я в интернете не нашёл. В этой статье мы расскажем, как работает этот плагин, какие преимущества он предлагает и как вы можете использовать его, чтобы достигать результатов на 100%. Давайте разберемся, как сделать вашу учебу проще и эффективнее с помощью этой уникальной технологии!
Ни один процесс разработки программы не проходит без отладки. Современные IDE обеспечивают программиста встроенным отладчиком. Однако бывают ситуации, когда использование IDE для отладки избыточно или невозможно, и тогда на помощь приходят автономные отладчики, один из которых — x64dbg.
Любые программные системы включают в себя нужные и не очень нужные пакеты. Получается огромный объём кода (для одного несложного сайта npm list -a выдаёт список из 4256 зависимостей). А так как «весь код — это ваш код», то такие зависимости надо тестировать. И регулятор требует, да и просто собственные продукты хочется защитить от вторжений, утечек и других неприятностей.
Critique и Gerrit
У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.
(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)
Дэшборды
Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).
В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).
Материал подготовлен на основе выступления с CppCon 2015 "Greg Law: Give me 15 minutes & I'll change your view of GDB" (доступно по ссылке ). Многие моменты я изменял и корректировал, поэтому учтите, что перевод достаточно вольный.
И да, вынесем за скобки вопрос о том, насколько GDB в целом удобная или неудобная программа, и что в принципе лучше использовать для дебаггинга: в данной статье будет рассматриваться именно работа с GDB.
В статье будет рассматриваться отладка кода на C в ОС Linux.
Колесо крутится, но хомячок подписки помер. Оно просто крутится.
В начале я хотел бы сказать, что описанные в статье практики очень плохи и неправильны (с тех пор мы добавили надёжные юнит-тесты и интеграционные тесты, а также систему алертов/логирования), что их следует избегать и в первую очередь это человеческие ошибки, которые задним умом кажутся очевидными.
Описанные в статье события произошли в условиях сильного дефицита времени на очень ранних этапах работы компании (первые несколько недель). По большей мере я публикую это как забавную историю с уникальными условиями, связанными с воспроизводимостью бага в продакшене (тоже из-за нашей собственной глупости). Пожалуйста, помните об этом, читая текст.
Впервые мы включили монетизацию нашего стартапа в мае прошлого года. Мы не ожидали многого, но были приятно удивлены тем, что меньше чем за час после запуска у нас появился первый клиент. Это был волшебный момент. Мы отправили ему благодарность, произнесли всей командой тост и пошли спать, ведь на подготовку мы потратили две ночи.
Проснувшись утром, мы увидели больше сорока уведомлений Gmail с жалобами пользователей. Похоже было, что за ночь поломалось всё. Никто из пользователей не мог подписаться. И мы понятия не имели, почему.