Понимайте свою программу без ущерба для производительности
Журналирование — это очень важная часть разработки ПО. Оно помогает разработчикам лучше понимать выполнение программы и судить о дефектах и непредвиденных сбоях. Журнальное сообщение может хранить информацию наподобие текущего статуса программы или того, в каком месте она выполняется. Если происходит ошибка, то разработчики могут быстро найти строку кода, которая вызвала проблему, и действовать с учетом этого.
Python предоставляет довольно мощный и гибкий встроенный модуль logging со множеством возможностей. В этой статье я хочу поделиться восемью продвинутыми возможностями, которые будут полезны при разработке ПО.
Код программных продуктов для машинного обучения часто бывает сложным и довольно запутанным. Обнаружение и ликвидация багов в нем — ресурсоемкая задача. Даже простейшие нейросети с прямой связью требуют серьезного подхода к сетевой архитектуре, инициализации весов, оптимизации сети. Небольшая ошибка может привести к появлению неприятных проблем.
Эта статья посвящена алгоритму отладки ваших нейронных сетей.
Так получилось, что в последние несколько лет я сшиваю Франкенштейнов, а не ваяю милые фарфоровые статуэтки пастушек и трубочистов. Я создаю решения на базе Magento 2. Это значит, что исходный материал у меня — мечта любого археолога. Культурный слой со следами различных "эпох" и "цивилизаций". По нему можно изучать развитие программистской мысли в PHP/JS сообществах в течение последнего десятилетия.
И это только базис, а надстройка — сторонние модули, которые нужно интегрировать вовнутрь. Вот тут уже можно столкнуться с проявлениями внеземного разума. Некоторые модули созданы развитыми существами, очень похожими по мышлению на создателей базиса, но попадаются такие, что хочется приобнять автора за плечо, проникновенно заглянуть ему в глаза и по-дружески так спросить: "Ты с какой планеты, родной?"
Сшить Франкенштейна из такого материала помогает отладчик (debugger). Ниже идёт мой персональный топ приёмов кодирования, которые способны усложнить жизнь любому, кто, как и я, ежедневно использует отладчик в своей жизни. Он небольшой, на четыре позиции, но каждый раз, когда я сталкиваюсь с подобным при отладке — я печалюсь. Может быть мой пост уменьшит количество скорбей в мире, а может и нет. Я, по крайней мере, попытаюсь.
Недавно при написании библиотеки к ESP-32 возникла необходимость ловить дедлоки, которые возникали иногда из-за моей криворукости, что породило необходимость покупки платы-отладчика с интерфейсом JTAG. Что из этого вышло — читайте под катом.
В компании Rollbar, которая занимается созданием инструментов для работы с ошибками в программах, решили проанализировать базу из более чем 1000 проектов на JavaScript и найти в них ошибки, которые встречаются чаще всего. В результате они сформировали список из 10 наиболее часто встречающихся ошибок, проанализировали причины их появления и рассказали о том, как их исправлять и избегать. Они полагают, что знакомство с этими ошибками поможет JS-разработчикам писать более качественный код.
Вы смотрите на код и не можете понять — почему! Почему он делает нечто неожиданное, и в общем-то, если не близится дедлайн, интересное. Однако от всех этих неожиданностей, в любом случае, надо избавляться.
Прежде чем вы, бросив всё остальное, кинетесь складывать в кучу найденные где-то строчки программ, которые, вроде бы, способны решить вашу задачу, ответьте пожалуйста на три вопроса:
Выполнение каких действий вы ожидаете от своей программы?
Почему вы ожидаете этого от программы?
Делает ли программа то, что вы от неё ожидаете?
Если вы не можете ответить на первых два вопроса — желаю удачи в копипасте, но, если вы знаете — что вы ожидаете от кода и почему — существуют инструменты, которые способны помочь вам понять, делает ли код то, чего от него ждут.
Всем привет! Данная серия статей — это текстовый вариант моего доклада на WSD в Киеве 26 ноября. Решил написать, чтобы дать более развернутое описание темам, которые были затронуты, а некоторые моменты уточнить. Кроме того, есть возможность рассмотреть больше примеров, услышать мнение от тебя, уважаемый читатель. И, конечно же, поделиться информацией с более широкой аудиторией.
В предыдущей статье я рассказал о своем первом знакомстве с DMA. В ней мы делали связку DMA + SysTick. Статья получилась очень специфичной и сложной, ввиду неопытного кривого подхода. Набравшись опыта, в данной статье я расскажу о куда более простом и понятном способе работы с DMA.
На Хабре уже неоднократнорассказывали о таком мощном и удобном средстве мониторинга HTTP-трафика, как Fiddler. Все имеющиеся статьи, однако, рассказывают о встроенных фичах программы, не акцентируя внимания на возможностях её расширения, которых существует целых две: с помощью встроенного языка FiddlerScript и с помощью написания .NET-плагинов. В этой статье мы рассмотрим и то, и другое, а чтобы было интереснее — используем их для решения вполне практической задачи, о которой я писал в своей прошлой статье (подмене битых ссылок на картинки в статьях на Хабре на рабочие).
Итак, давайте вспомним для начала, чем закончилась прошлая статья: мы получили список нерабочих ссылок на картинки и соответствующих им рабочих ссылок на веб-архиве. Теперь нужно отдать их браузеру и для этого мы напишем расширения к Fiddler (одно на FiddlerScript и одно на .NET). Обратите внимание на удобства полученного решения: да, нам нужно будет запустить Fiddler, но зато битые ссылки будут подменяться на рабочие независимо от домена статьи (хабр, гиктаймс или мегамозг), независимо от используемого браузера (лишь бы имел поддержку прокси) и даже мобильные устройства можно будет настроить на использование установленного на компьютере Fiddler в качестве прокси.
В этой статье дается простая короткая инструкция как пропатчить third-party приложение под iOS что бы отключить ASLR при отладке. Предполагается что у читателя в наличии:
iOS 7.0-7.0.4 устройство с evasi0n jailbreak и компьютер с Mac OS X 10.9.4, установленным XCode 5.1.1 и МаchOView 2.4 (скорее всего для других версий тоже будет работать, но я не пробовал)
некоторый опыт в отладке third-party приложения для iOS, ну и желательно знать что такое ASLR и понимать зачем его отключать
UseCase 0: надоело переподключать плату с RP2040 и захотелось загружать прошивку из IDE по кнопке "Run" UseCase 1: хочется пошаговой отладки, а не принтами.
Установил на одну из плат DebugProbe и попробовал подключиться.
Оказалось не все так просто - OpenOCD плевался на неизвестное устройство:
Привет, Хабр! Меня зовут Владимир Захаров (@vzkhrv), я расскажу про SSR. На самом деле, утечки памяти работают в JavaScript везде – и на сервер-сайте, и на клиенте, поэтому информация будет полезна даже тем, у кого пока нет SSR. Давайте чуть подробнее познакомимся. Я ведущий фронтэнд-разработчик, около 8 лет в отрасли. В Зарплате.ру больше не работаю, но основной опыт, о котором хочу рассказать, получен именно там. Я люблю плавающие баги, разговоры о техдолге и шутки про ненастоящих программистов. Поговорим про утечки в памяти в SSR, про работу с памятью и про то, как всё это выглядит в браузере и в nodejs. Ну, и естественно, как со всем этим жить.
Люди, которые пишут код, часто воспринимают работу с исключениями как необходимое зло. Но освоение системы обработки исключений в Python способно повысить профессиональный уровень программиста, сделать его эффективнее. В этом материале я разберу несколько тем, изучение которых поможет всем желающим раскрыть потенциал Python через разумный подход к обработке исключений.
Всем привет! Меня зовут Александр, я занимаюсь backend-разработкой в KTS.
В одной из прошлых статей мы рассказали про архитектуру фронтенд-приложения для проекта личного кабинета сотрудников Пятёрочки. В этой статье расскажу, как мы решали проблему персонализации интерфейса пользователя на бэкенде и с какой проблемой столкнулись через какое-то время.
Изначально вторая главазадумывалась только, как шпаргалка по работе из оперативной памяти, но делать и разбираться в этом не очень трудно. Основная "запара" может настигнуть несведущего именно при работе с прерываниями. Собсна, решено объединить.
В недавних примечаниях к патчам была строка «Исправлена ошибка создания земли под игроком при создании земли в другом месте». Подробнее об этом можно прочитать здесь. Некоторых пользователей Reddit заинтересовало, как вообще мог возникнуть такой баг, они попросили объяснить более развёрнуто и даже предложили использовать эту информацию для нашего блога Factorio Friday Facts. Я подумал: «Да, если я потрачу время на написание этого текста, нам стоит взять его в FFF, чтобы никому другому не пришлось писать о чём-то другом».
Баг с созданием земли, отчёт о котором был отправлен после выпуска версии 0.18.21.
Примечание: меня ещё не было в компании, когда разворачивалось действие старых частей этой истории (кстати, недавно был мой пятилетний юбилей в Wube, ура!), а подробности изменений, свидетелем или даже участником которых я был, могли запомниться неверно. Поэтому изложение истории может быть неточным. Можно вообще сказать, что всё это плод вымысла и любые совпадения с реальными событиями и людьми являются простым совпадением.
Переходы между тайлами… снова
В первые пару лет разработки Factorio вода отрисовывала вокруг тайлов земли переходные тайлы. Графика переходных тайлов занимала у тайлов земли слишком много пространства, поэтому было невозможно нарисовать один тайл земли, окружённый водой, как и мост шириной в один тайл, проходящий по воде. Кроме того, переходная графика сочеталась только тайлами травы. Для учёта этих ограничений генератор карт был дополнен этапом коррекции, цель которого заключалась в том, чтобы рельеф можно было отрисовывать без графических артефактов.
Рис. 1. Ушиблен, но не сломлен. Калькулятор Windows, чей код недавно опубликован на Github, оказался одним из двух протестированных приложений, которые не зависли и не упали в противостоянии с фаззером оконных сообщений разработки 2000 года. Размер окна специально увеличен, чтобы показать артефакты фаззинга
Настало время для второй части наших усилий по проверке древних методов фаззинга на современных системах. Если вы пропустили, вот первая часть. На этот раз мы опробуем на Windows 10 методы фаззинга из статьи «Эмпирическое исследование надёжности приложений Windows NT с использованием случайного тестирования» (она же «отчёт по фаззингу NT») Джастина Форрестера и Бартона Миллера, опубликованной в 2000 году.
Исследователи протестировали 33 приложения Windows NT и ранней версии Windows 2000 на восприимчивость к искажённым оконным сообщениям и случайным событиям мыши и клавиатуры. Поскольку д-р Миллер опубликовал код фаззера, мы использовали в точности те же инструменты, что и первоначальные авторы, для поиска ошибок в современных приложениях Windows.
На Хабре уже писали про перехват системных вызовов с помощью ptrace; Алекса написал про это намного более развёрнутый пост, который я решил перевести.
С чего начать
Общение между отлаживаемой программой и отладчиком происходит при помощи сигналов. Это существенно усложняет и без того непростые вещи; ради развлечения можете прочесть раздел BUGS в man ptrace.
Есть как минимум два разных способа начать отладку:
ptrace(PTRACE_TRACEME, 0, NULL, NULL) сделает родителя текущего процесса отладчиком для него. Никакого содействия от родителя при этом не требуется; man ненавязчиво советует: «A process probably shouldn't make this request if its parent isn't expecting to trace it.» (Где-нибудь ещё в манах вы видели фразу «probably shouldn't»?) Если у текущего процесса уже был отладчик, то вызов не удастся.
ptrace(PTRACE_ATTACH, pid, NULL, NULL) сделает текущий процесс отладчиком для pid. Если у pid уже был отладчик, то вызов не удастся. Отлаживаемому процессу шлётся SIGSTOP, и он не продолжит работу, пока отладчик его не «разморозит».
Эти два метода полностью независимы; можно пользоваться либо одним, либо другим, но нет никакого смысла их сочетать.
Я наткнулся на статью Нареша Джоши о копировании и клонировании и был удивлён ситуацией с производительностью. У клонирования есть проблемы с финальными полями. А учитывая тот факт, что интерфейс Cloneable не предоставляет метод clone, то для вызова clone вам необходимо будет знать конкретный тип класса.
Большинство потребителей имеют уже сложившееся мнение о том, что касается услуг web-хостинга. Если вы будете искать отзывы о любом хостинг-провайдере, вы обнаружите десятки результатов. И обычно, негативных отзывов там намного больше, чем положительных. Я думаю, я смогу это исправить, поэтому делюсь с вами задачами, с которыми мне приходится сталкиваться как оператору поддержки хостинга для WordPress, а также их решениями.
Я собрал список плохих web-решений, а также рекомендаций о том, чего делать на вашем сайте не стоит. Список основывается на тысячах часов общения с клиентами, а также поддержки и устранения неполадок, с которыми я сталкиваюсь ежедневно. Что-то из предложенного будет достаточно примитивным, а какие-то вопросы будут более продвинутого уровня. Многое из описанного может отделять успешный сайт на WordPress от провального. Ведь, несмотря на то, что выбор правильного web-хостинга очень важен, вы должны уделять достаточно времени оптимизации сайта на WordPress, чтобы он был успешным.