Пару дней назад 0xd34df00d опубликовал здесь перевод статьи, описывающей, что можно узнать о функции в разных языках, если рассматривать её как "чёрный ящик", не используя информацию о её реализации (но, разумеется, не мешая ей пользоваться компилятору). Разумеется, получаемая информация очень сильно зависит от языка — в исходной статье рассматривались четыре примера:

• Python — динамически типизированный, информации минимум, какие-то подсказки дают только тесты;
• C — слабо статически типизированный, информации ненамного больше;
• Haskell — сильно статически типизированный, с чистыми функциями, информации существенно больше;
• Idris — язык с зависимыми типами, информации достаточно, чтобы во время компиляции доказать корректность функции.

"Есть C, есть Haskell, а где же Rust?!" — немедленно прозвучал вопрос. Ответ — под катом.

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

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



Откуда он взялся? Из простой мысли, что иногда люди выходят из офиса поесть что-то снаружи. Ближайший магазин у нас в 10 минутах от офиса (с учётом спуска-подъёма). Гораздо дешевле и практичнее принести сотрудникам бесплатную еду, чем тратить их время на её поиски, пускай и не за счёт компании. Сначала это были только здоровые закуски, но потом по мере роста офиса стали появляться сосиски, а для тех, кто иногда остаётся ждать ночи перед релизом, — пицца. При этом горячая еда тут не хранится постоянно, а приезжает отдельно.

Давайте проанализируем, как такое решение вообще могло быть принято.

Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Этот цикл будет состоять из четырех частей:

• Буферный кеш (эта статья);
• Журнал предзаписи — как устроен и как используется при восстановлении;
• Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
• Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Блокировки:

1. Блокировки отношений;
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

Часть 1. Молнии

В этой части мы рассмотрим процесс рендеринга молний в Witcher 3: Wild Hunt.

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


Они очень быстро исчезают, поэтому лучше просматривать видео на скорости 0.25.

Можно увидеть, что это не статичные изображения; со временем их яркость слегка меняется.

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

В прошлой статье я рассказал, как пишу конспекты по математике на LaTeX в Vim. В этой статье покажу, как создаются рисунки для этих конспектов с помощью Inkscape, а также расскажу о своём самодельном менеджере горячих клавиш.

Некоторые примеры

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

Что такое шум Перлина?

Шум Перлина придуман в 1983 году Кеном Перлином (получившим за это достижение премию Американской Академии кинематографических искусств и наук). Видите ли, в те времена все стремились к фотореализму, но его всегда не хватало. Кен Перлин придуман этот алгоритм шума, чтобы избавиться от жалкого «компьютерного» внешнего вида 3D-моделей. Шум — это генератор случайных чисел в компьютерной графике. Это случайный неструктурированный паттерн, он полезен в тех случаях, когда требуется источник подробных деталей, недостающих в очевидной структуре¹. Шум Перлина — это многомерный алгоритм, используемый в процедурной генерации, текстурах, генерации рельефа, генерации карт, генерации поверхностей, генерации вершин, и так далее, и тому подобное.

При разработке ПО для микроконтроллеров на С++ очень часто можно столкнуться с тем, что использование стандартной библиотеки может привести к нежелательным дополнительным расходам ресурсов, как ОЗУ, так и ПЗУ. Поэтому зачастую классы и методы из библиотеки std не совсем подходят для реализации в микроконтроллере. Существуют также некоторые ограничения в использовании динамически выделяемой памяти, RTTI, исключений и так далее. В общем случае, чтобы писать компактный и быстрый код нельзя просто так взять библиотеку std и начать пользоваться, скажем операторами типа typeid, потому что необходима поддержка RTTI, а это уже накладные расходы, хоть и не очень большие.

Поэтому иногда приходится изобретать велосипеды, чтобы выполнить все эти условия. Таких задач немного, но они есть. В данном посте, хотелось бы рассказать про вроде бы как простую задачку — расширить коды возврата существующих подсистем в ПО для микроконтроллера.

Настало время как я разобрался с freetype2. Теперь я хочу сделать так, чтобы мой код стал доступен нуждающимся. Потому как обдумывать, как работать с библиотекой, не всегда есть время. Я хочу показать код работы именно с freetype и немного с opengl. Немного о коде. Я не могу создавать сложный код. У меня все получается как-то по-простому. Я видел несколько фрагментов кода, работающего с freetype2, и никак не мог понять, как он на самом деле работает. Уж очень сложный код создавали авторы. Я надеюсь, что мой простой код вам понравиться. После прочтения этой статьи можно будет создать многострочный текст и отобразить одной текстурой на экран.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Несколько месяцев назад завершился мой проект по изготовлению USB-клавиатуры. Среди прочего, я выполнил дизайн электронных схем, спроектировал печатную плат, запрограммировал прошивку, сделал макет в CAD и произвёл сборку устройства. В результате получилась удобная клавиатура, которую я использую ежедневно и ласково называю KeeBee:


Клавиатура KeeBee в окончательном виде

Несколько целей проекта:

1. Самостоятельное создание схемы.
   
2. Написание прошивки клавиатуры.
   
3. Узнать, как работает протокол USB.

В течение многих лет Intel холила и развивала свою технологию RealSense, выпускала новые версии RealSense SDK и новые камеры — самая свежая модель была представлена буквально в конце прошлого года. В статье, посвященной анонсу, мы кратенько вспомнили историю технологии и ее принципы, не преминув подчеркнуть, что RealSense — это, прежде всего, карта глубины, придающая трехмерность окружающей действительности и многократно расширяющая возможности ее интерпретации. И вот новый поворот: свет увидела Intel RealSense Tracking Camera T265, работающая совсем по-другому.

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


Рисунок 1. Сравнение различных квазислучайных последовательностей с низким расхождением. Заметьте, что предлагаемая мной $$-последовательность создаёт более равномерно распределённые точки, чем все остальные методы. Более того, все остальные методы требуют тщательного подбора базовых параметров, а в случае неправильного подбора приводят к вырожденности (например справа вверху)

Рассматриваемые в статье темы

• Последовательности с низким расхождением в одном измерении
• Методы с низким расхождением в двух измерениях
• Расстояние упаковки
• Множества с многоклассовым низким расхождением
• Квазислучайные последовательности на поверхности сферы
• Квазипериодический тайлинг плоскости
• Маски дизеринга в компьютерной графике

Какое-то время назад этот пост был выложен на главной странице Hacker News. Можете прочитать там его обсуждение.

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Pseudo Lens Flare» автора John Chapman.



Lens flare (блики на линзах) ― это фотографический артефакт, возникающий при рассеивании и преломлении света в системе линз. Хотя он является артефактом, существует множество поводов использовать lens flare в компьютерной графике:

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

Традиционно lens flare в realtime реализовывался с помощью технологий, основанных на спрайтах. Хотя спрайты дают легко контролируемые и очень реалистичные результаты, они должны быть размещены явно и требуют данные окклюзии для корректного отображения. Здесь я опишу простой и относительно дешевый screen space эффект, который создает псевдо lens flare из входного color buffer. Он не основан на физике, поэтому результат немного отличается от фотореалистичного, но его можно использовать в комбинации с (или как замену) традиционными sprite-based эффектами.

Пришли очередные выходные, надо написать пару десятков строк кода и нарисовать картинку, да лучше не одну. Итак, на прошлых и позапрошлых выходных я показал, как делать трассировку лучей и даже взрывать всякое. Это многих удивляет, но комьпютерная графика — очень простая вещь, пары сотен строк голого C++ вполне хватает на создание интересных картинок.

Тема сегдоняшнего разговора — бинокулярное зрение, причём сегодня даже до ста строк кода не дотянем. Умея рендерить трёхмерные сцены, было бы глупо пройти мимо стерепар, сегодня будем рисовать примерно вот такое:

Приветствую всех. На просторах aliexpress наткнулся на очередное китайское творение, из раздела "Беспроводные модули для arduino". Ранее подобные модули с аналогичными возможностями за столь малые деньги мне не попадались. Вот я и решил сделать обзор данного модуля. Возможно, кого-то он заинтересует. Речь пойдет о маломощном трансивере JDY-40, работающем на частоте 2,4 Гигагерца. Работать с модулем очень просто, для настройки модуля используются ат команды, которые передаются по USART.

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

Как всегда, в нашем распоряжении только голый компилятор, никаких сторонних библитек использовать нельзя. Я не хочу заморачиваться с оконными менеджерами, обработкой мыши/клавиатуры и тому подобным. Результатом работы нашей программы будет простая картинка, сохранённая на диск. Я совершенно не гонюсь за скоростью/оптимизацией, моя цель — показать основные принципы.

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

TL;DR;

Совсем недавно ( примерно с 1983 года ) оказалось, что OpenSSH, как наследник rsh, для команды scp ( ex. rcp ) позволяет серверу выбрать, какой файл и с какими параметрами вам передать. А уязвимости вывода позволяют скрыть, какой именно файл вам передали.
То есть просите вы file.txt, а получаете — exploit.bin
И фиксов пока нет, вот такие дела. Используйте sftp или rsync.

Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.

Для примера будем использовать:

Домен = contoso.com
Контроллер домена = dc.contoso.com

В прошлый раз мы рассмотрели вариант генерации импульсов для шаговых двигателей, частично вынесенный с программного на микропрограммный уровень. В случае полного успеха, это сулит отсутствие необходимости обрабатывать прерывания, поступающие с частотой вплоть до 40 КГц. Но тот вариант обладает рядом явных недостатков. Во-первых, там не поддерживаются ускорения. Во-вторых, гранулярность допустимых частот шагов в том решении — сотни герц (например, возможна выработка частот 40000 Гц и 39966 Гц, но невозможна выработка частот с величиной между этими двумя значениями).