Отладка *

Некоторое время назад, вернувшись после полугодового отпуска в функциональном мире, назад в ООП, я в который раз наступил на привычные грабли: случайно изменил состояние.

private double fBm(Vector2D v, int y)
{
    double result = 0f;
    double freq = Frequency;

    for (int i = 0; i < Octaves; ++i)
    {
        result += NoiseFn(permutation, v * freq) * Amplitude;
        freq *= Lacunarity;
        Amplitude *= Gain; // <-- Вот тут.
    }

    return result;
}

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

За свой относительно небольшой опыт работы (порядка 6 лет) я довольно часто слышал фразы опытных и начинающих программистов — «Я чувствую, что это должно работать», «У меня есть ощущение, что этот метод работать не будет», «Давайте сделаем интуитивно-понятный интерфейс» и так далее. Всё это — проявление интуиции в процессе разработки и программировании.
О ней и пойдёт дальше разговор.


Взято с сайта oprah.com

Однажды мне пришлось вычислять сумму векторов целых чисел.

Звучит необычно. Кому понадобится делать это в реальной жизни? Обычно такие вычисления встречаются только в задачках из начальной школы или бенчмарках компилятора. Но сейчас это случилось на самом деле.

В реальности стояла задача проверить контрольную сумму заголовков IPv4, которая является суммой обратных кодов (дополнений до единицы) двухбайтных машинных слов. Проще говоря, это означает сложение всех слов и всех битов переноса, которые производятся в процессе. У этой процедуры есть несколько приятных особенностей:

• её можно эффективно выполнить с помощью процессорной инструкции ADC (к сожалению, эта функция недоступна в C);
• её можно выполнить на словах любого размера (можете добавить по желанию восьмибайтные значения, только результат следует уменьшить до двух байт и добавить все биты переполнения);
• она нечувствительна к порядку следования байтов (удивительно, но это так).

Вступление

Довольно долгое время я использовал в своей работе screen. Но со временем он меня перестал устраивать. Я начал искать альтернативы. Такой альтернативой является tmux. На многих порталах его описывают так: «Это тот-же screen, только на стероидах». Сначала я не мог понять почему такое сравнение пока не попробовал. Скажу честно, я на него не с первого раза перешел. Раза три-четыре пробовал, возвращался к screen’у. Но tmux все же победил.

По следам аналогичной публикации о технических ошибках систем, приводящих к ошибкам в расчётах с клиентами, публикую обещанную историю с МТС. Не реклама. :)

Был август. До 2-го курса студента Василия Задёрганова (персональные данные изменены) оставалось несколько дней. Он был доволен летним интернетом от МТС на тарифе «МТС Коннект-4» по услуге «МТС-Планшет» — 4 ГБ трафика в месяц. И оставался последний день услуги и последний нескачанный гигабайт.

«Эх, скачаю фильм, и укачу на последние дни на природу!» — безмятежно подумал Василий. У него было просчитано всё. Он знал истории об облапошенных велосипедистах-любителях, у которых из-за незакрытого велозамка на прокате массово списывают тысячу рублей. Он знал, что вернут деньги лишь избранным, кто хорошо и красиво напишет об этом и прославит сервис на всю страну. Но это — не его путь. Он сделал всё, чтобы не пострадать. Он — стратег.

1) заранее для интернета завёл отдельную сим-карту;
2) заранее оставил для подлых крохоборов лишь 20 непотраченных рублей на счёте; а мог и меньше; но верил им, что побрезгуют такой мелочью;
3) в Личном Кабинете отключил опции законного жульничества — автоматической оплаты сверхлимитного трафика по повышенному тарифу;
4) там же отключил опцию «передавать трафик на услуге сверх лимита».

Вы поняли, какая перестраховка? Это вам не тракторист Федя, которого вы в этом сезоне обули на рекламе. Кто-то бы успокоился на отключении первой опции, а тут ему — вторая, не автоматическая. Вася — не такой.

… До конца его сим-карты оставалась пара часов.

Всё началось, как и многие другие расследования, с баг-репорта.

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

Вступление

Всем привет! Данная серия статей — это текстовый вариант моего доклада на WSD в Киеве 26 ноября. Решил написать, чтобы дать более развернутое описание темам, которые были затронуты, а некоторые моменты уточнить. Кроме того, есть возможность рассмотреть больше примеров, услышать мнение от тебя, уважаемый читатель. И, конечно же, поделиться информацией с более широкой аудиторией.

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

Проект был под угрозой, но мощные инструменты отладки операционной системы и отличная работа программистов на Земле (парни, что надо) позволили в кратчайшие сроки все быстренько исправить.

Чем сложнее программный продукт, чем больше он взаимодействует со сторонними системами (часто не менее сложными), тем выше вероятность сбоев в работе. Тестирование помогает найти большинство багов перед выкатыванием релиза, но иногда что-то может проскользнуть. И чтобы быстро получать подробную информацию о факте сбоя и сопутствующих условиях, в наших продуктах широко используется система отчётов. О её устройстве мы хотим сегодня рассказать.

Как провести связь третьего и четвертого поколения туда, где в ходу лишь 2G из-за того, что горы мешают прямой видимости базовых станций, а для установки дополнительных БС нет необходимых энергомощностей? Наш эксперт Константин Кильбер расскажет о соответствующем опыте компании МТС – на примере установки активного ретранслятора для радиорелейной линии в маленьком поселке в Республике Адыгея в 2015 году. Итак, передаем слово нашему специалисту.

Задача перед нами стояла непростая: обеспечить максимальную пропускную скорость от базовой станции в поселке Гузерипль, Республика Адыгея. Это такое место у подножия Главного Кавказского хребта, на высоте 670 метров над уровнем моря, с населением чуть более 100 человек.

Главной проблемой стали горы – они мешали прямой видимости радиорелейных станций (РРС), которые являются транспортной составляющей для базовых станций. Ранее был построен пассивный ретранслятор (без активного оборудования): две радиорелейные антенны, соединенные между собой волноводом. Сигнал от радиорелейной станции (РРС 1) приходит на одну антенну, через волновод сигнал попадает на вторую антенну, далее сигнал идет на вторую часть радиорелейной станции (РРС 2). Пропускная способность радиорелейной линии с пассивным ретранслятором составляла не более 30 Мбит/с, что для современной связи очень мало. При таком раскладе может работать только базовая станция 2G, а вот с 3G и LTE уже возникают сложности.

Продолжаем эксперимент, начатый месяцем ранее, когда мы построили Wi-Fi сеть с бесшовным роумингом и прошлись по офису с планшетом, наблюдая, будут ли происходить замирания и сбои при скачивании на него потокового видео? Эксперимент прошел удачно, проблем с потоком не было и отчет выложили здесь же на Хабрахабр. Но!

Но в комментариях к статье были выражены сомнения, ввиду того, что видеопоток мог буферизоваться и бесшовный вай-фай эмулировался за счет подкачки видео еще до перехода от одной точки доступа к другой и это видео, из буфера воспроизводилось после обрыва и восстановления сессии. Отвечая на эти вопросы мы снова нагрузили абсолютно ту же сеть, с теми же точками Edimax, ничего не меняя в их настройках (поднял те же параметры для другого SSID, чтобы не мешать офису со своими тестами по RADIUS серверу, который так же обкатываю для работы в этой сети). Использовали почти что голосовой трафик, который нельзя было заподозрить в буферизации. С удовольствием делимся результатами второй части эксперимента.

Как сделать ваш код лаконичным и послушным одновременно?

Вам когда-нибудь встречалось приложение, которое вело себя очевидно странно? Ну, вы знаете, вы нажимаете на кнопку и ничего не происходит. Или экран вдруг чернеет. Или приложение впадает в «странное состояние» и вам приходится перезагружать его, чтобы все снова заработало.

Если у вас был подобный опыт, то вы вероятно стали жертвой определенной формы защитного программирования (defensive programming), которую я бы хотел назвать «параноидальное программирование». Защитник осторожный и рассудительный. Параноик испытывает страх и действует странно. В этой статье я предложу альтернативный подход: Offensive programming.

«Ошибка в Pentium настолько специфичная, что обычный пользователь столкнется с ней раз в 27000 лет»
— руководство Intel

«Вот вам правдоподобный сценарий, когда пользователь будет сталкиваться с ошибкой каждые 3 миллисекунды»
— Воэн Пратт (дизайнер логотипа SUN и соавтор алгоритма Кнута-Морриса-Пратта)

66 MHz Intel Pentium (sSpec=SX837) with the FDIV bug

Вопрос: Сколько нужно разработчиков Pentium чтобы вкрутить лампочку?
Ответ: 1.99904274017, такой ответ должен удовлетворить людей без технического образования.

А теперь главный вопрос: «Чем занимался Томас Найсли с начала июня до конца октября 1994 года?»

11 февраля 1991 года Patriot Project Office получил израильские данные о дефекте в ракетной системе Patriot. Они нашли, что если система работает 8 часов, она начинает мазать на 20%. Они прикинули, что после 20 часов работы система начинает промахиваться настолько, что перестанет быть способной захватывать, отслеживать и поражать баллистические ракеты. Американские военные не приняли во внимание всю важность открытия, заявив, что система предназначена для портативных и краткосрочных защитных операций и что никто никогда не будет использовать систему больше 8 часов.

16 февраля был выпущен Bug Fix, но чтобы его внедрить во все единицы боевой техники, требовалось время, ибо война.

21 февраля военные выпускают указание, что система не должна работать «долго». Военные не уточнили сколько длится «долго».

25 февраля в Дахране (Саудовская Аравия) в казарму в гости к американцам прилетела баллистичекая ракета "керосинка" (она же Р-17, она же Scud). 28 убито 96 ранено, потому что ЗРК «Патриот» промахнулся из-за программной ошибки.

26 февраля Bug Fix был доставлен в Дахран.

Мы не любим ждать в очереди, хотим сделать заказ онлайн, мы не готовы покупать билет в кассе, пусть все будет в приложении, в электронном виде. И вот тут есть важное «Но»! Мы всё хотим здесь и сейчас, но чтобы это работало без сбоев, как часы. Доставку пиццы осуществили вовремя, место в кинотеатре совпало с полученным в подтверждении. Что во всем этом многообразии приложений и сервисов играет одну из ключевых ролей?

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

Зачем все это было нужно и к чему мы пришли?
Какое будущее нас ждет?

Поговорим «за тестирование» с гуру профессии. Пройдёмся от А до Я по инструментарию. Помогут нам в этом Игорь Хрол и Антон Семенченко.

Запасаемся кофе, чаем, другими напитками и начинаем. Беседа будет долгой.

Итак, Игорь Хрол — специалист по автоматизации тестирования в Toptal. Игорь имеет большой опыт работы с большинством популярных инструментов (Selenium, HP QTP, TestComplete, JMeter).

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

PostgreSQL, как и любая другая СУБД, умеет делать некоторые проверки при вставке/изменении данных, и этим обязательно нужно уметь пользоваться. Давайте посмотрим, что мы можем проверять:

1. Кастомный подтип через ключевое слово DOMAIN

Люди: — Эй, Тойота, мы тут посчитали, у вас из-за корявой электроники и софта 89 человек погибло с 2000 по 2010.
Тойота: — Да они сами виноваты, путают педали.
Люди: — Хьюстон, у нас проблемы.
NASA: — Ща разберемся, нам надо 10 месяцев и 3 миллиона долларов.
Люди: — На.
Тойота: — 3 миллиона мало, вот вам еще сверху кэшем.
(прошло 10 месяцев)
NASA: — Эй, Тойота, мы у вас пару ошибок в коде нашли, а точнее 7134 нарушения стандартов MISRA, рекурсию, функцию на 740 строк и 9000 глобальных переменных.
Тойота: — А у нас свои стандарты. А вы ваще на Луну летали?
NASA (публично): — Тойота ни в чем не виновата.
(Акции Тойота подскочили на 4,6%)
Люди: — Ну ё-моё.
(спустя 3 года)
Два американских тестировщика (у которых дедушки погибли в Перл-Харбор): — Нет багов? А если найдем?

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

Оптимизации, которые влияют на скорость вычислений при использовании любого числа потоков, сводятся к учёту в коде особенностей процессорных архитектур, наборов инструкций, к поиску наиболее рациональных способов работы с разными видами памяти. Помощь в подобной оптимизации способен оказать, например, подход к исследованию производительности методом «сверху вниз» с использованием низкоуровневых данных о системных событиях, которые преобразуются в доступные для анализа и практического применения высокоуровневые показатели.



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