«Мы не можем ожидать, что у нас получится отобразить объект точно таким, каким он является в реальности, с текстурами, тенями и т.д. Мы надеемся только на то, чтобы создать изображение, которое достаточно близко к достижению определённой степени реализма».

Буй Тыонг Фонг

Буй Тыонг Фонг родился в 1941 году и стал учёным-информатиком во время Вьетнамской войны. Должно быть, ему сложно оказалось завершить своё обучение в токсичной среде 60-х, не говоря уже о том, что его призвали на фронт! Но ему удалось выжить и дожить до 1975 года, прежде чем его жизнь забрала лейкемия спустя всего два года после того, как он заложил для мира фундамент современной теории освещения и затенения: шейдер Фонга.

В этой статье вас ждёт десять лучших докладов от Андрея Александреску, Дэвида Вандервурда, Джона Калба и многих других.

Фичи компилятора C++, асинхронность, многопоточность, параллелизм, модель памяти, алгоритмы и STL, метапрограммирование и рефлекшен, огромное множество тем.

Всё это — записи с конференции C++ Russia, самой большой в истории. Восемь сотен участников, немаленький зал, спикеры с мировым именем. Прошёл год, но большинство докладов ничуть не утратило своей актуальности. Впрочем, и неудивительно — именно такие доклады и попадают в топ по оценке участников.

Формат таков:

• Обязательное видео на YouTube
• Слайды, если есть
• Подробное описание доклада на русском языке
• Краткая биография докладчика

Плюс у вас есть комментарии Хабра, чтобы обсудить увиденное. Реклама на ютубе отключена, никто не будет мешать. Есть всё, чтобы начать смотреть прямо сейчас.

Где-то в альтернативной вселенной, согласно MWI, я стал гениальным физиком. Но в этой вселенной просто подробно слежу за профессиональными публикациями в области физики, зарабатывая себе на хлеб развозкой пиццы базами данных. Как следствие чуть более глубоких знаний, я не могу смотреть никаких научно-популярных передач. Это как железом по стеклу — тут oversimplification, тут просто неверно, тут есть тонкости…

Я решил сформировать список наиболее часто встречающихся неправд и полуправд. Итак, самое частое это…

Большой взрыв

Его изображают примерно так:

Некоторое время назад ссылка на статью "Modern dining philosophers" распространилась по ресурсам вроде Reddit и HackerNews. Статья интересная, она показывает несколько решений этой известной задачи, реализованных на современном C++ с использованием task-based подхода. Если кто-то это статью еще не читал, то имеет смысл потратить время и прочесть ее.

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

При этом task-based подход не является единственным возможным для решения подобных задач. Почему бы не посмотреть, как задача "обедающих философов" решается посредством моделей Акторов и CSP?

Посему попробовал посмотреть и реализовал несколько решений этой задачи как с использованием Акторов, так и с использованием CSP. Код этих решений можно найти в репозитории на GitHub-е. А под катом пояснения и объяснения, так что кому интересно, милости прошу под кат.

Это вторая (и последняя) часть гайда по созданию водопада в Unity или UE4 после вдохновения игрой RiME. В первой разобрались с инструментами, выбрали среду разработки и создали шейдер кругов на воде. Почему начали именно с этого? Все просто: там используется большинство методов, которые сейчас понадобятся при создании водопада. Но тут есть и свои хинты. Тянуть не будем — давайте под кат.

В 1974 году британский математик Роджер Пенроуз создал революционный набор плиток, который можно использовать для заполнения бесконечной плоскости никогда не повторяющимся узором. В 1982 году израильский кристаллограф Даниэль Шехтман открыл металлический сплав, атомы которого были выстроены в порядке, никогда ранее не встречавшемся в материаловедении. Пенроуз достиг масштабного общественного признания, редко достающегося математикам. Шехтман получил Нобелевскую премию. Оба учёных бросили вызов человеческой интуиции и изменили основы понимания структуры природы, обнаружив, что бесконечная вариативность может возникать даже в высокоупорядоченной среде.

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

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым 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).

Привет Хабр.

Данный пост является логическим завершением публикаций про жизненный цикл статьи на Хабре (первая и вторая части для тех кто интересуется технической стороной вопроса), в результате чего был сделан достаточно интересный инструмент для статистического анализа. Методика оказалась весьма полезной, и позволяет находить статьи по различным параметрам, например, статьи с самым высоким «качеством» (соотношением рейтинга к числу просмотров), самые «спорные» статьи, у которых больше всего полярных комментариев, самые комментируемые материалы, и пр.



Пора теперь извлечь из этого какую-то пользу, и составить статистический рейтинг статей за 2018 год. В идеале это хорошо было бы сделать к началу Нового Года, но умные мысли бывает, приходят с запозданием. Но лучше поздно чем никогда, это позволит перечитать какие-то полезные статьи тем, кто пропустил их в свое время. И небольшой «секретный бонус» в конце текста для тех, кто будет достаточно любопытен.

Тех, кому интересно что получилось, прошу под кат.

Эту четырёхминутную короткометражку сделал студент из Нью-Йорка

Анимационные фильмы, созданные при помощи шлема VR, не являются особой новинкой. Но большинство из них – это отдельные сцены, зацикленные в повторяющуюся петлю типа анимированного GIF. Возможно, там двигается камера, выхватывает какие-то детали, но как таковой истории там нет. Но мультфильм Wired – это дело другое. Это один из первых анимационных фильмов, созданных в VR, содержащий несколько сцен и выраженную историю. Эта прекрасная короткометражка показывает жизнь мальчика, изучающего мир без беспроводных технологий. Он падает с кабеля, натянутого над огромными небоскрёбами, что заставляет местных жителей взглянуть вверх и насладиться небом.

С лета 1976-го коротковолновую связь по всему миру начал терроризировать «эфирный хулиган». На ряде частот, выделенных для гражданской связи и авиации, поселился характерный стучащий сигнал с частотой 10 импульсов в секунду, мешающий переговорам и трансляциям во множестве стран. Этот стук доводил до белого каления как радиолюбителей, так и тех, для кого радиосвязь была профессиональным инструментом. Судите сами:

https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Woodpecker.ogg

Причём сигнал был «плавающий» — поработав несколько минут на одной частоте, он переходил на другую. Загадочность и создаваемые неудобства привели к тому, что военные ряда стран попытались запеленговать источник. Оказалось, что он расположен в глубине Советского Союза. А поскольку сигнал — к тому времени получивший прозвище «Русский Дятел», — периодически вторгался на частоты, зарезервированные для авиации, этим не замедлили воспользоваться США, Великобритания и Канада, заявившие СССР протест. СССР сделал удивлённое лицо и ответил, что ничего не знает ни о каком сигнале.

_{Изображение взято из Викимедии, автор – Gil. Распространяется на условиях лицензии Creative Commons Attribution 2.0 Generic license}

Привет, Хабр! Меня зовут Андрей, я юрист в сфере интеллектуальной собственности и IT-технологий.

Некоторое время назад на Хабре была опубликована история andrei_mankevich — автора мобильного приложения — реализации игры «Балда», которое было удалено по жалобе правообладателя соответствующего товарного знака. Судя по комментариям к этой истории, многим было интересно, можно ли как-то восстановить справедливость и наказать тролля.

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

На заметку: «патентные тролли» («patent troll») — это лица, осуществляющие покупку или регистрацию патента на изобретение, полезную модель или промышленный образец исключительно для того, чтобы требовать с других лиц вознаграждение за использование патента под угрозой предъявления судебного иска. Такие лица, как правило, не производят какой-либо полезный продукт на основании купленного патента.

В отношении лиц, осуществляющих аналогичную деятельность с товарными знаками и объектами авторских прав, используются, соответственно, термины «trademark troll» (можно перевести как «брендовый тролль») и «copyright troll» («копирайтный тролль», «копитролль»).
Далее я буду говорить о брендовых троллях — лицах, которые регистрируют или покупают товарные знаки, для того чтобы заработать на предъявлении претензий и судебных исков.

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

Если вы разрабатываете приложения для XAML-based платформ, таких как WPF, Silverlight, Windows Phone, или Windows Store, то Prism, определённо, сильно поможет вам упростить их разработку. После создания нескольких проектов с использованием Prism, я убедился в работоспособности такого подхода и решил подготовить перевод официального руководства Prism. Итак, часть первая, что же такое Prism.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Prism является руководством, разработанным для того, чтобы помочь проектировать и создавать насыщенные, гибкие и легко поддерживаемые Windows Presentation Foundation (WPF) приложения, Silverlight Rich Internet Applications (RIAs), и программы под Windows Phone 7-8, а также Windows Store приложений. Используя паттерны проектирования, которые воплощают важные принципы архитектурного дизайна, такие как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling), Prism помогает вам проектировать и писать приложения со слабо связанными компонентами, которые могут независимо развиваться и потом объединяться в одно целое с минимальными усилиями. Этот тип приложений известен как составные приложения.

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

Привет, хаброразработчик!
Нет, это не очередной конкурс спали клавиатуру А и получи клавиатуру Г. Сегодня мы поговорим о горячих клавишах в Visual Studio 2008.

Всем привет! Так случилось, что моя статья – первая в блоге группы компаний ЛАНИТ на Хабре. Очень рад этой возможности, осознаю ответственность и надеюсь, что материалы нашего блога будут для вас интересны.

Итак, к делу. Гиперконвергентные системы становятся сегодня одним из основных решений в области построения ИТ-инфраструктуры корпоративного уровня. В этой статье я кратко расскажу о том, что из себя представляют такие системы и в каких случаях при развертывании ИТ-инфраструктуры они могут быть полезны. Также я поделюсь результатами сравнения технических возможностей ряда гиперконвергентных платформ, которые мы изучили при планировании развития ИТ-инфраструктуры облака OnCloud.ru компании «Онланта».

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

Нижележащий текст преследует несколько целей:

1. Дать краткий обзор (читай — немного погундеть на тему) неудовлетворительного состояния инструментария, применимого к хтоническим чудовищам мира C/C++;
2. Предложить своё альтернативное решение (бесплатно-без-СМС-и-регистрации — проект некоммерческий и выложен на GitHub под MIT-лицензией);
3. Призвать сообщество пообщаться на тему и собрать идеи;
4. Пригласить присоединиться к разработке проекта на GitHub.

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

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

Для начала расскажу немного о том, что это:

Audiere — это высокоуровневый аудио-API с открытым исходным кодом под лицензией LGPL. Его можно использовать во множестве языков, включая Java, C++, Python, Delphi и др. Разрешается использовать в коммерческих приложениях свободным образом, если исходный код не будет затронут (подробности в документации к библиотеке).

Игры на Unreal Engine, разработка на Unreal Engine, туториалы для Unreal Engine и другие интересные материалы об Unreal Engine вы найдете в нашем дайджесте. И кажется, мы забыли упомянуть самое главное – дайджест посвящен Unreal Engine.

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