Одна из первых действительно интересных задач по математике, с которыми я столкнулся формулируется так: "из шахматной доски вырезали две противоположные по диагонали угловые клетки, можно ли оставшуюся часть разрезать на "доминошки" — фигурки из двух клеток, у которых одна сторона общая?". У нее очень простая формулировка, в отличие от великой теоремы Ферма она имет простое, элегантное, но неочевидное решение (если вы знаете решение задачи, то попробуйте применить его к фигуре справа).

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

Когда я был молодым, мне всегда хотелось иметь наборы «техникс» от Lego, чтобы собирать из них всякие крутые штуки. Автономные танки с вращающимися турелями, стреляющими кирпичиками Lego. Но тогда такого набора у меня не было.

И даже обычных кирпичиков от Lego не было. У меня был только друг, у брата которого были все эти дорогие игрушки.

А теперь у меня самого сын такого возраста. И он строит танки, которые… тупо прут вперёд, пока не врежутся в стену :)

И вот, настало время для ESP32 и магии паяльника – соберём для них правильный пульт дистанционного управления!

Нет, я, конечно, знаю о существовании таких пультов. Но ни один из них мне не подходит полностью. Они либо инфракрасные, с технологией 80-х годов, либо слишком крупные. Или дорогие. А главное – ни об одном из них я не смогу сказать сыну: «Я сделал это специально для тебя!»

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

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

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

Оглавление

23 апреля состоялся релиз Ubuntu версии 20.04 с кодовым названием Focal Fossa, являющимся следующим выпуском Ubuntu для долгосрочной поддержки (LTS) и является продолжением Ubuntu 18.04 LTS, выпущенной в 2018 году.

Немного про кодовое имя. Слово «Focal» означает «центральная точка» или «самая важная часть», то есть связано с понятием средоточия, центром каких-либо свойств, явлений, событий, а «Fossa» имеет корень «FOSS» (Free and Open-Source Software — свободное и открытое программное обеспечение) и по традиции именования версий Ubuntu названиями животных означает Фосса — самое крупное хищное млекопитающее из семейства виверровых с острова Мадагаскар.

Учёные-информатики вышли на новые рубежи в деле проверки решений задач вычислительными методами. При этом они нашли ответы на важнейшие открытые вопросы квантовой механики и чистой математики.

В 1935 году Альберт Эйнштейн, работая с Борисом Подольским и Натаном Розеном, исследовал возможность, открытую новыми законами квантовой физики: две частицы могут находиться в запутанном состоянии, когда их взаимосвязь не нарушают даже огромные расстояния.



В следующем году Алан Тьюринг сформулировал первую общую теорию вычислений, и доказал, что существуют задачи, которые никогда не смогут быть решены компьютерами. 

Эти две идеи произвели революцию в тех областях наук, к которым они относятся. Кроме того, казалось, что они не имеют никакого отношения друг к другу. Но теперь доказательство MIP* = RE их скомбинировало, что привело к решению множества задач в сфере информатики, физики и математики.

Предисловие

Современные компиляторы обладают огромным количеством диагностик. И удивительно, что очень малая их часть включена по умолчанию.

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

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

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

Команда Rust опубликовала новый корректирующий выпуск Rust, 1.41.1. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.41.1 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта

Что вошло в стабильную версию 1.41.1

Rust 1.41.1 посвящён двум критическим регрессиям, появившимся в Rust 1.41.0: некорректность в статических временах жизни и неправильная компиляция, вызывающая ошибки сегментирования. Эти регрессии не затрагивают предыдущие выпуски Rust и мы рекомендуем пользователям Rust 1.41.0 обновиться настолько быстро, насколько это возможно. Другая проблема, связанная со взаимодействием между временем жизни 'static и реализациями типажа Copy, присутствовала ещё с Rust 1.0 и тоже исправляется данным выпуском.

На Github-e выложен OSINT-инструмент, заточенный (в том числе) для поиска %username по СНГ локации

【Статья обновлена】в связи с развитием функционала Snoop Project.
Если вам до боли знаком такой софт, как namechk или spiderfoot, то «Snoop Project» вас явно порадует, он даёт «им» фору вместе взятым и это не желтый заголовок «Статья вечерняя» — это реальная «forensic-работа» по цифровым следам в киберпространстве…

Наверняка, каждый, кто хоть раз писал что-то на Python, задумывался о том, как распространять свою программу (или, пусть даже, простой скрипт) без лишней головной боли: без необходимости устанавливать сам интерпретатор, различные зависимости, кроссплатформенно, чтобы одним файлом-exe'шником (на крайний случай, архивом) и минимально возможного размера.

Для этой цели существует немало инструментов: PyInstaller, cx_Freeze, py2exe, py2app, Nuitka и многие другие… Но что, если вы используете в своей программе PyQt? Несмотря на то, что многие (если не все) из выше перечисленных инструментов умеют упаковывать программы, использующие PyQt, существует другой инструмент от разработчиков самого PyQt под названием pyqtdeploy. К моему несчастью, я не смог найти ни одного вменяемого гайда по симу чуду, ни на русском, ни на английском. На хабре и вовсе, если верить поиску, есть всего одно упоминание, и то — в комментариях (из него я и узнал про эту утилиту). К сожалению, официальная документация написана довольно поверхностно: не указан ряд опций, которые можно использовать во время сборки, для выяснения которых мне пришлось лезть в исходники, не описан ряд тонкостей, с которыми мне пришлось столкнуться.

Данная статья не претендует на всеобъемлющее описание pyqtdeploy и работы с ним, но, в конце концов, всегда приятно иметь все в одном месте, не так ли?

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

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

Rust становится первоклассным языком в самых разных областях. Мы в Discord успешно используем его и на серверной, и на клиентской стороне. Например, на стороне клиента в конвейере кодирования видео для Go Live, а на стороне сервера для функций Elixir NIF (Native Implemented Functions).

Недавно мы резко улучшили производительность одной службы, переписав её с Go на Rust. В этой статье объясним, почему для нас имело смысл переписать службу, как мы это сделали и насколько повысилась производительность.

Многие используют в своей работе Jupyter Notebooks. Но с ростом сложности проекта появляются проблемы. В блокноте появляются ячейки с красными пометками для самого себя «перед запуском укажи число...» или «задай количество итераций исходя из...». Какой-то откат к командной строке получается.

Да и вывод данных на экран не всегда воспринимается без пояснений сторонним человеком, который привык к красивым таблицам, картинкам и прочим современным элементам интерфейса.

Доказательство на стыке чистой математики и теории алгоритмов возвышает «квантовую запутанность» на совершенно новый уровень.

Фраза «I shit bricks» в статье от Nature — бесценно. Да, это настолько неожиданный результат, что Nature позволяет себе вольности. (от переводчика)

Квантовая запутанность находится в сердце нового математического доказательства.Credit: Victor De Schwanberg/Science Photo Library

Первая часть: Основы работы с видео и изображениями

---

Что? Видеокодек — это часть программного/аппаратного обеспечения, сжимающая и/или распаковывающая цифровое видео.

Для чего? Невзирая на определённые ограничения как по пропускной способности так
и по количеству места для хранения данных, рынок требует всё более качественного видео. Припоминаете, как в прошлом посте мы подсчитали необходимый минимум для 30 кадров в секунду, 24 бита на пиксель, с разрешение 480x240? Получили 82,944 Мбит/с без сжатия. Сжатие — это пока единственный способ вообще передавать HD/FullHD/4K на телевизионные экраны и в Интернет. Как это достигается? Сейчас кратко рассмотрим основные методы.

Вторая часть: Принципы работы видеокодека

---

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

Если рассматривать итоговый цвет как комбинацию т.н. основных цветов (красного, зеленого и синего), в нашей трёхмерной матрице определяем три плоскости: первая для красного цвета, вторая для зеленого и последняя для синего.

Будем называть каждую точку в этой матрице пикселем (элементом изображения). Каждый пиксель содержит информацию об интенсивности (обычно в виде числового значение) каждого цвета. Например, красный пиксель означает, что в нём 0 зеленого цвета, 0 синего и максимум красного. Пиксель розового цвета может быть сформирован с помощью комбинации трех цветов. Используя числовой диапазон от 0 до 255, розовый пиксель определяется как Красный = 255, Зелёный = 192 и Синий = 203.

Привет, Гиктаймс!

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

Это перевод статьи Элиезера Юдковского, из научно-популярного цикла, посвященного многомировой интерпретации квантовой механики. Начало цикла было переведено на хабре, но потом переводчик видимо подустал. Его можно понять — материал очень объемный. Юдковский любит растекаться мыслию по древу. С другой стороны, материал действительно сложный, а повторение разными словами одного и того же позволяет картинке в голове неподготовленного читателя хоть как-то уложиться. Я не возьмусь продолжить перевод всего цикла, но попробую перевести пару наиболее важных статей.

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

А вот следующий пост отвечает на важный вопрос. Если "настоящий" мир на фундаментальном уровне — квантовый, где все запутано, и все влияет друг на друга, откуда вообще берутся классические системы? Почему "естественные" квантовые явления мы видим так редко в обычной жизни? Это то что автор называет "классической галлюцинацией". Почему, например, создателям квантовых компьютеров нужно прикладывать такие огромные усилия, чтобы сохранить систему в "естественном" запутанном состоянии?

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

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

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