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

Первое и самое главное, что нужно знать - квантовые компьютеры не имеют ничего общего с обычными. Квантовые компьютеры по своей природе - аналоговые, там нет бинарных операций. Вероятно, вы уже слышали про Кубиты, что у них есть состояние 0, 1 и 0-1 одновременно, и благодаря этому вычисления выполняются очень быстро: это заблуждение. Кубит - это магнит (обычно атом или электрон), подвешенный в пространстве, который может вращаться по всем трем осям. Собственно, вращение магнита в пространстве - это и есть операции квантового компьютера. Почему это может ускорить вычисления? Было очень сложно найти ответ, но самые стойкие читатели увидят его в конце статьи. Начнем разоблачения.

К моему удивлению, на столь популярный сервис, как Яндекс диск, не нашлось примеров записи файла на диск на языке программирования C#. На PHP же ситуация обратная, примеров вдоволь, например: https://snipp.ru/php/disk-yandex

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

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

В первую очередь это касается реалтайм игр, которые критичны к сетевым задержкам, имеют активное общение клиента и сервера, например, 10 - 60 раз в секунду и используют UDP протокол.

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

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

Бывало, замечаешь в коде «нехороший» модуль или функцию и тут же тянутся руки их отрефакторить. Но как потом убедиться, что правки не сломали какой-нибудь сценарий в приложении или вовсе не положили продакшен? Этих ситуаций можно избежать, если в проекте есть тесты. 

Меня зовут Александр Моргунов, я техлид в Самокате. Пишу на TypeScript, React, ReactNative. В разное время писал тесты для фронтенда, бэкенда и мобилок. В этом посте хочется поговорить о том, как можно тестировать современные фронтенд-приложения и какие подходы к тестированию сейчас актуальны. 

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

Последние 4-5 десятилетий спрос на программистов вырос в сотни раз. По некоторым оценкам их количество удваивается каждые пять лет, и в результате программист с 5-летним опытом работы имеет стаж работы в отрасли больший, чем у половины всех ее сотрудников.

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

Специально для своего блога Эрик попытался обобщить весь свой опыт в виде кратких советов, которые он хотел бы дать молодым программистам. Под катом — наиболее важные, на взгляд автора, уроки и выводы из его 20-летней карьеры.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

Серия моих предыдущих статей о здоровье и его компьютерном анализе и просто о ЗОЖ и фитнесе-физкультуре:

Бег в 2023 г. С пятки или с носка? Измеряем ударные нагрузки. Android и акселерометр
https://habr.com/ru/post/714698/

Как быстро бег уничтожает колени. Опрос любителей и мнение профессионалов
https://habr.com/ru/post/709182/

Сделайте это и бегать будет легче, чем ходить. Упражнение для тренировки летящего бега, получите удовольствие от бега
https://habr.com/ru/post/705954/
65 тыс. прочтений.

Теория Информации и Machine Learning мне видятся как интересная пара областей, глубокая связь которых часто неизвестна ML инженерам, и синергия которых раскрыта ещё не в полной мере.

Начнём с базовых понятий Энтропии, Информации в сообщении, Mutual Information, пропускной способности канала. Далее будут материалы про схожесть задач максимизации Mutual Information и минимизации Loss-а в регрессионных задачах. Затем будет часть про метрику Фишера, геодезические и градиентные методы, и их связь с гауссовскими процессами.

Понятие Mutual Information (MI) связано с задачей прогноза. Собственно, задачу прогноза можно рассматривать как задачу извлечения информации о сигнале из факторов. Какая-то часть информации о сигнале содержится в факторах. И если вы напишите функцию, которая по факторам вычисляет число близкое к сигналу, то это и будет демонстрацией того, что вы смогли извлечь MI между сигналом и факторами.

Привет Хабр!

В этой статье будет разобрана работа Unreal Header tool, рефлексии, и немного затронем VM.

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

Материал я собрал, изучая такие сайты, как researchgate.net, sciencedirect.com, www.ncbi.nlm.nih.gov, escholarship.org и другие. Опираясь на эти данные, я занимаюсь разработкой оптимальной рецептуры гигиенической (т.е. не лечебную) зубной пасты, стараясь добиться оптимального баланса между абразивными, антибактериальными и реминерализирующими свойствами (плюс - еще желательно позаботиться об окружающих зуб тканях).

Зачем? 1. Потому что очень интересно; 2. Потому что не хватает этого баланса в современных не лечебных продуктах (лечебные должны работать в одну цель, там совсем иная история в этом плане).

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

О чём будет: разные способы обработки ошибок в C++, несколько советов от сообщества и немного заметок о различных жизненных (и не очень) ситуациях.

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

Так, стандарт вводит отдельное требование BitmaskType, описывающее свойства, какими должны обладать битовые маски в стандартной библиотеке: для них должен быть определены операции «и», «или», «не», а значение 0 должно представлять пустую маску.

В стандартной библиотеке классов, от которых требуется соблюдение этого требования, очень много: std::chars_format, std::launch, std::filesystem::perms, std::filesystem::perm_options, std::filesystem::copy_options, std::filesystem::directory_options... Единственное, чем они отличаются — это набором возможных значений. Реализации же битовых операций над ними похожи как две капли воды.

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

В разработке программного обеспечения иммутабельным (immutable — неизменяемым) называется объект, который после своего создания не может быть изменен. Зачем вам может понадобиться такой объект? Чтобы ответить на этот вопрос, давайте проведем анализ проблем, которые могут возникнуть в результате мутации (изменения) объектов. Вернемся к основам того, что делает каждое приложение: создает, извлекает, обновляет и удаляет данные (CRUD-операции). Ядро любого приложения манипулирует объектами. Ответ на вопрос о том, работает ли приложение в соответствии со своей спецификацией, в первую очередь определяется правильностью обработки данных. Вам необходимо быть уверенными, что код работает правильно, каждый раз, когда он затрагивает какой-либо объект. 

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

Если ваше приложение является многопоточным, иммутабельность должна быть фундаментальной частью вашей архитектуры, поскольку неизменяемые объекты по своей природе являются потокобезопасными и невосприимчивыми к состояниям гонки. Если ваше приложение использует data transport objects (DTO — объекты передачи данных), вам также следует серьезно подойти к иммутабельности ваших объектов. Предметом дискуссий остается лишь то, как наиболее эффективно реализовать и работать с иммутабельными объектами, поскольку C# не предлагает встроенной поддержки таких объектов. Эта статья предлагает ответ на этот вопрос.

Когда я взялась решать задачку по динамическому программированию — реализовать алгоритм, который рассчитывает расстояние Левенштейна — мне пришлось послушать пару небольших лекций и прочесть несколько статей (приведу их в конце), чтобы разобраться. Я решила попытаться пересказать алгоритм настолько просто, чтобы по этому объяснению можно было снять ролик для тиктока (когда он снова возобновит свою деятельность в РФ). Дальше — мало формул и много картинок.

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

Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.

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

После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".

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

Всем привет, это Денис Вебер.

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

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