Рубрика «ненормальное программирование» - 37

Разработка программ высокого качества подразумевает, что программа и её части подвергаются тестированию. Классическое модульное (unit) тестирование подразумевает разбиение большой программы на маленькие блоки, удобные для тестов. Либо, если разработка тестов происходит параллельно с разработкой кода или тесты разрабатываются до программы (TDD — test driven development), то программа изначально разрабатыватся небольшими блоками, подходящими под требования тестов.

Одной из разновидностей модульного тестирования можно считать propery-based testing (такой подход реализован, например, в библиотеках QuickCheck, ScalaCheck). Этот подход основан на нахождении универсальных свойств, которые должны быть справедливы для любых входных данных. Например, сериализация с последующей десериализацией должна давать такой же объект. Или, повторная сортировка не должна менять порядок элементов в списке. Для проверки таких универсальных свойств в вышеупомянутых библиотеках поддерживается механизм генерации случайных входных данных. Особенно хорошо такой подход работает для программ, основанных на математических законах, которые служат универсальными свойствами, справедливыми для широкого класса программ. Есть даже библиотека готовых математических свойств — discipline — позволяющая проверить выполнение этих свойств в новых программах (хороший пример повторного использования тестов).

Иногда оказывается, что необходимо протестировать сложную программу, не имея возможности разобрать её на независимо проверяемые части. В таком случае тестируемая программа представляет собой черный белый ящик (белый — потому что мы имеем возможность изучать внутреннее устройство программы).

Под катом описаны несколько подходов к тестированию сложных программ с одним входом с разной степенью сложности (вовлеченности) и разной степенью покрытия.

Читать полностью »

Работа со строками на этапе компиляции в современном C++ - 1

Если вы программируете на C++, то наверняка задавались вопросом почему нельзя сравнить два строковых литерала или выполнить их конкатенацию:

auto str = "hello" + "world"; // ошибка компиляции

if ("hello" < "world") { // компилируется, но работает не так, как ожидалось
    // ...
}

Впрочем, как говорится, "нельзя, но если очень хочется, то можно". Ломать стереотипы будем под катом, причем прямо на этапе компиляции.

Читать полностью »

В данной статье будут приведены основы внутреннего устройста типов, а также пример, в котором память под ссылочный тип будет выделена полностью на стеке (это потому что я full-stack программист).

Ломаем фундаментальные основы C#: выделение памяти под ссылочный тип на стеке - 1

Дисклеймер

Данная статья не содержит материал, который стоит применять в реальных проектах. Это просто расширение границ, в которых воспринимается язык программирования.

Прежде, чем приступить к повествованию, настоятельно рекомендую ознакомиться с первым постом про StructLayout, т.к. там разобран пример, который будет использоваться в этой статье (Впрочем, как и всегда).
Читать полностью »

2_fview_gameplay

История, которую я расскажу, началась 13 лет назад на уроке информатики. Мы с друзьями-семиклассниками решили все задачи на Паскале и весело играли в первый Quake. Наша учительница увидела это, подошла ко мне и сказала всего одну фразу, которая перекосила мою картину мира: «Если ты хочешь играть в игры на уроке, пиши их сам». С тех пор я эпизодически делаю игры. Одна из них — футбольный симулятор, о котором и пойдёт речь.

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

Читать полностью »

Однажды я готовился к Ludum Dare и сделал простую игру, где использовал пиксельные шейдеры (других в движок Phaser не завезли).

Что такое шейдеры?

Шейдеры — это программы на си-подобном языке GLSL, которые выполняются на видеокарте. Есть два вида шейдеров, в этой статье речь идет про пиксельные (они же “фрагментные”, fragment shaders), которые очень грубо можно представить в таком виде:

color = pixelShader(x, y, ...other attributes)

Т.е. шейдер выполняется для каждого пикселя выводимого изображения, определяя или уточняя его цвет.
Вводную можно почитать на другой статье на хабре — https://habr.com/post/333002/

Потестировав, кинул ссылку другу, и получил от него вот такой скриншот с вопросом "а это нормально?"

Как я попробовал сделать статический анализатор GLSL (и что пошло не так) - 1

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

if (t < M) {
    realColor = mix(color1,color2, pow(1. - t / R1, 0.5));
}

Т.к. константа R1 была меньше чем M, то в некоторых случаях в первом аргументе pow получалось число меньше нуля. Квадратный корень из отрицательного числа — штука загадочная, по крайней мере для стандарта GLSL. Мою видеокарту ничего не смутило, и она как-то выпуталась из этого положения (похоже, вернув из pow 0), а вот у друга она оказалась более разборчивой.

И тут я задумался: а могу ли я избежать таких проблем в будущем? От ошибок никто не застрахован, особенно таких, которые не воспроизводятся локально. Юнит-тесты на GLSL не напишешь. В то же время преобразования внутри шейдера довольно простые — умножения, деления, синусы, косинусы… Неужели нельзя отследить значения каждой переменной и убедиться, что ни при каких условиях не происходит выхода за допустимые границы значений?

Так я решил попробовать сделать статический анализ для GLSL. Что из этого получилось — можно прочитать под катом.

Сразу предупрежу: какого-то законченного продукта получить не удалось, только учебный прототип.

Читать полностью »

image

Анонимные стрелочные функции в JavaScript, согласно некоторым опросам — самая популярная фича ES-2015, что также подчеркнуто исчерпывающим числом туториалов в интернете. Они бесспорно очень полезны, но в этой небольшой статье мы рассмотрим примеры использования обделенных вниманием не менее замечательных выражений с именованными функциями — NFE.

Читать полностью »

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

Дисклеймер

Прежде, чем приступить к повествованию, настоятельно рекомендую ознакомиться с первым постом про StructLayout, т.к. там разобран пример, который будет использоваться в этой статье.

Весь код, кроющийся за высокоуровневым, представлен для режима отладки, именно он показывают концептуальную основу. JIT оптимизации — это отдельная и большая тема, которая здесь рассматриваться не будет.

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

Начинаем с теории

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

Что происходит за кулисами С#: основы работы со стеком - 1

Читать полностью »

image

Можно ли блюрить Лапласом вместо Гаусса, во сколько раз это быстрее, и стоит ли того потеря 1/32 точности.
Читать полностью »

image

«Блюр» в простонародье — эффект размытия, в цифровой обработке изображений. Бывает очень эффектен и сам по себе, и как составляющее анимаций интерфейса, или более сложных производных эффектов (bloom/focusBlur/motionBlur). При всем этом честный блюр в лоб довольно медленен. И часто реализации встроенные в целевую платформу оставляют желать лучшего. То скорость печальна, то артефакты режут глаза. Ситуация рождает множество компромиссных реализаций, лучше или хуже подходящих для определенных условий. Оригинальная реализация с хорошим качеством достоверности и высочайшей скоростью, при этом нижайшей зависимостью от аппаратной части ждет вас под катом. Приятного аппетита!
Читать полностью »

Язык программирования Rockstar: когда код выглядит как текст рок-хита - 1

Словосочетание «rockstar developer» заставляет некоторых морщиться: «вот же глупый рекрутерский баззворд, среди самих разработчиков никто так себя не называет». В России оно встречается не так часто, а вот в англоговорящих странах многим уже надоело. И особенно остро ощущает его засилье британский .NET-разработчик Дилан Битти: он фанат рок-музыки, поэтому хорошо видит, насколько это «rockstar» далеко от настоящих rockstars.

В итоге Дилан затеял язык программирования Rockstar, код на котором должен быть похож на рок/метал-тексты. Во-первых, если получится сделать такой проект заметным, то можно отнять у рекрутеров слова «rockstar developer», дав им новое значение. А во-вторых, интересно же попробовать скомпилировать тексты любимых песен! Ну и делать наклейки на ноутбук «certified rockstar developer» тоже весело.

Конечно, всё это звучит как шутка, и изначально ей и было, но теперь становится всё реальнее. Подробности — под катом.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js