Отладка *

Вы используете в своем приложении электронную почту, не так ли? Это, в общем-то, риторический вопрос, конечно используете. Ей уже больше 30 лет, а это по прежнему самое популярное средство коммуникации на планете. Вот некоторые статистические данные от Pingdom:

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

Потрясающе!

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

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

Я уверен, вы знаете о чем я говорю. Думая, что перевели приложение в режим отладки, вы запускаете тест, который отправляет письма из вашего приложения. Вы думаете что никто кроме вас не увидит эти письма.

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

Было такое? Не хочется, чтобы повторилось? Есть решение — MailCatcher. Если вы не слышали о нем то вкратце:

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

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

Сейчас я хочу показать вам, как настроить, запустить и использовать MailCatcher.

В этой статье я расскажу о простом методе заработка в сети перехвата HTTP/HTTPS трафика iOS приложений, включая трафик приложений использующих certificate pinning (а это например Twitter, Facebook и куча других приложений). От прочих методов, где бедным людям рекомендуют в командной строке руками генерировать какие-то сертификаты и куда-то их запихивать, этот метод отличается (относительной) безгеморройностью, хотя кое-какие телодвижения сделать конечно прийдется.

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

DDMS (Dalvik Debug Monitor Server) — безумно полезный инструмент для отладки приложений, который идет в комплекте с Android SDK, о котором почему-то особо и не сказано на хабре, впрочем как и в примерах google он представлен в очень скромном виде. Я бы хотел раскрыть его возможности и показать на что он способен. Вкратце:

• изучать информацию о работающих потоках;
• анализировать heap на количество свободной и занятой памяти;
• анализировать какие объекты чаще создаются, их размер и другое (Allocation tracker);
• находить проблемные участки кода, которые долго работают и требуют оптимизации (Method profiling). Это я советую знать всем.

Об этих вещах будет рассказано в рамках данной статьи. И для справки, менее интересное, что довольно тривиально и о чем НЕ будет рассказано в рамках данной статьи:

• работать с файловой системой эмулятора или устройства;
• находить информацию об ошибках (привет LogCat);
• эмулировать звонки/смс/местоположение;
• использовать инструмент Network Statistics.

Все идет от лени. Вы получили чужой очень большой проект в котором нужно сделать небольшие правки, или же написали скрипт и сразу не очевидно, что в нем еще требует оптимизации. Как быть? Читать и анализировать код, выводить каждый шаг на экран или в файл (var_dump() и т.д.) не всегда эффективно, ведь можно воспользоваться средствами отладки, которых на сегодняшний день очень много. Кратко перечислю часто встречающиеся…

Эта простая статья скорее для начинающих разработчиков Java, хотя я нередко вижу и опытных коллег, которые беспомощно глядят на stack trace, сообщающий о NullPointerException (сокращённо NPE), и не могут сделать никаких выводов без отладчика. Разумеется, до NPE своё приложение лучше не доводить: вам помогут null-аннотации, валидация входных параметров и другие способы. Но когда пациент уже болен, надо его лечить, а не капать на мозги, что он ходил зимой без шапки.

Итак, вы узнали, что ваше приложение упало с NPE, и у вас есть только stack trace. Возможно, вам прислал его клиент, или вы сами увидели его в логах. Давайте посмотрим, какие выводы из него можно сделать.

Приветствую тебя, уважаемый читатель!

Offtop

В этом топике я хотел бы рассказать о том, как можно получать доступ к тому, что принадлежит нам, но косвенно.
Любой софт — это чья-то собственность: кто-то сидел и шевелил своими мозгами, чтобы произвести на свет очередное «чудо».
Но вне наших девайсов речи о софте не может и быть. Понятие «софт», в таком случае, будет означать не более чем «мягкость».
Это очевидно.
Именно поэтому мы имеем право вытворять с любым программным кодом, выполняющимся на нашем устройстве, все, что пожелает душа…

Intro

Думаю, начать стоит с самого начала. Все началось с моего обнаружения пользовательской зависимости окружающих к небезызвестной игре 2048. Мне, конечно же, стало интересно, чем эта игра так захватывает людей, поэтому я решил сам ее попробовать. Через несколько минут я понял ее суть и мне эта игра тоже стала интересна.
Должен признаться, более 5000 очков мне набирать не удавалось никак, а до 2048 было еще слишком долго…
Тем временем окружающие «игроки» с легкостью набивали по 10-16тыс очков, а некоторым удавалось даже достигать 2048 в клетке.
Что ж, спустя некоторое время у меня возникла идея тупо взломать эту игру, чтобы не «убивать» время на ее прохождение( она слишком долгая в прохождении, но от этого не менее затягивающая ). А еще спустя пару дней, об этом же меня попросили и мои знакомые.
Это означало одно: пора браться за дело…

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

Недавно я уже поднимал волну о баге TCP стриминга камер, но тогда я её катил исключительно на китай. А проблема куда как шире. Для себя я проблему решил, страждущим выкладываю прошивки с фиксом.

А теперь садитесь поудобнее, я поведаю вам об этом баге подробно.

Введение в «Checkpoint Group»

Понятие и реализация «Сheckpoint Group» изначально появились в SAP Web Application Server (SAP WebAS) 6.20 и целиком относятся к области контроля правильности и возможности отслеживания переменных. При грамотном применении, технология облегчает работу по отладке и повышает качество ABAP кода.

Mozilla выпустила инструмент, который наверняка многим облегчит жизнь: это фреймворк RR под Linux для записи и последующего воспроизведения хода выполнения программы. Воспроизведение происходит абсолютно детерминированно, то есть с теми же регистрами и адресами памяти — и неизменно с тем же сбоем (если он был). Другими словами, можно бесконечно гонять тесты, а как только появится баг — не спеша его изучить в офлайне, прокрутив запись сколько угодно раз. Записываются все деревья процессов и потоков.

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

Многие интернет-магазины попадают в Яндекс.Маркет, не все там остаются надолго. Одно из условий присутствия в ЯМ-е – наличие корректного прайса в специальном формате YML.

Проверка такого прайса на ошибки и устранение таковых – целая история. Пока он не будет сформирован по всем правилам – вход в сие царство демпинга заказан. А при доведении документа до ума можно пережить немало незабываемых эмоций.

Данная статья – попытка обобщить те ошибки, с которыми сталкиваются программисты, впервые создающие инструменты (будь то автономный скрипт или плагин для CMS) для генерации YML-файла. Тем, кто с этим чудным форматом имел дело раньше, статья уже будет не столь интересна, ибо всё шишки набиты. Впрочем, вдруг и ветераны борьбы за своё место под солнцем Яндекса узнают что-то новое для себя. А то и поделятся собственным фронтовым опытом.

В этой статье мы ищем (и, что характерно, находим!) критический баг в CoreGraphics в iOS. Сразу скажу, что на полноценную уязвимость этот баг конечно не тянет — его эксплуатация не приводит, например, к arbitrary code execution. Однако этот баг позволяет аварийно завершать приложения которые используют WebKit: Mobile Safari, Google Chrome для iOS, всяческие почтовые клиенты и т.п., что тоже может быть полезно для хакера в некоторых ситуациях. Итак, приступим к поискам.

Всем привет! Меня зовут Дмитрий Чепель, я — эксперт в компании Acronis. Так уж получилось, что ко мне обращаются с проблемами, которые не удалось решить моим коллегам. Кто-то думает, что у меня есть некое «разработческое чутьё», интуиция. Не знаю, как вы, а я считаю, что интуиция — это такой же инструмент разработки, как и остальные, и её можно и нужно улучшать и тренировать.

В связи с узурпацией должности управдома нашего МКД, и необходимости «причесать» общественный беспорядок, потихоньку конструирую систему видеонаблюдения.
Разумеется, финансирование минимальное, планы — грандиозные, поэтому собирается всё из подножного корма.
Подробности чуть позже, а вот один из интересных багов, который заставил перебрать много чего.

Итак, началось всё с малого — простенькая купольная камера, бралась самая паршивая по принципу "только б IP и купол". После пошел процесс перебора софта (тема отдельного поста, будет, опять же, позже)… В конце зафиксировался на Macroscop в один канал. Стояла пару месяцев, есть-пить не просила, наркоманов гонять помогала.

И вот работает вроде всё, но как-то подлагивает периодически. Грешил на всё: на проц, на сеть, на софт, на погоду на марсе… Саппорт по логам говорит, что-де камера периодически отваливается.

Upd

В качестве среды разработки компанией «Мультиклет» был выбран текстовый редактор Geany с основными функциями интегрированной среды разработки. Для поддержки необходимых для отладки инструментов разработчиками компании «Мультиклет» был написан плагин MC-DBG, о тестировании возможностей которого пойдет речь в данной статье.

Я уверен, что у многих из нас при отладке приложений периодически возникает желание отступить на шаг (или два, десять...) назад от текущей строки, чтобы увидеть причины происходящего в ней неправильного поведения. Чаще всего для этого приходится перезапускать отладку с начала и пытаться остановить исполнение программы чуть раньше, чем на предыдущей попытке. Затем надо пошагово приблизиться к предполагаемому месту с проблемой… упс, опять перешагнули! Начинаем всё по новой, ведь в дебаггере уже нельзя отступить назад даже на один шаг. Или можно?

В одном из своих предыдущих постов я запланировал описать, как программная симуляция цифровых систем позволяет делать то, что невозможно в реальности, а именно — обращать вспять течение времени для нужд отладки. Об этом и пойдёт речь в этой заметке.


^{Автор фото: Иван Андреев}

Это перевод статьи Джошуа Блоха «Extra, Extra — Read All About It: Nearly All Binary Searches and Mergesorts are Broken» 2006 года.

Я живо помню первую лекцию Джона Бентли в университете Карнеги-Меллон, на которой он попросил нас, свежеиспечённых аспирантов, написать функцию двоичного поиска. Он взял одно из решений и разобрал его на доске, и, разумеется, в нём оказалась ошибка, как и во многих других наших попытках. Этот случай стал для меня наглядной демонстрацией к его книге «Жемчужины программирования». Мораль в том, чтобы внимательно расставлять инварианты в программе.

И вот, теперь 2006 год. Я был потрясён, узнав, что программа двоичного поиска, корректность которой Бентли доказывал формально и тестами, содержит ошибку. Не подумайте, что я придираюсь; по правде сказать, такая ошибка вполне может ускользать от тестеров десятилетиями. Более того, двоичный поиск, который я написал для JDK, тоже был багнутым лет девять. И только сейчас, когда она сломала кому-то программу, о ней сообщили в Sun.

Биржевые и околобиржевые компании создают серьезный спрос на программистов, занятых совершенно разными вещами — от автоматизации бэкофиса до дата майнинга. Очень серьезные зарплаты и ответственность имеют разработчики так называемых High Frequency Trading algorithms, высокочастотных торговых алгоритмов. Написать этот пост меня сподвиг один занудный и одновременно забавный фильм (youtube, 50 минут, без перевода), в котором разработчик Хаим Бодек очень просто объясняет суть происходящего в HFT.

Поток заявок на покупку-продажу в биржевом "стакане" Бодек ассоциирует с очередью за редким товаром, которого не хватает

Вчера узнал об одной изящной возможности отладки в «Инструментах разработчика Chrome». На конференции "Web Developer Conference Compact" Маркус Росс (Marcus Ross — @zahlenhelfer) рассказывал о различных инструментах отладки, реализованных в Chrome, об одном из который я хочу рассказать.