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

Идея проста: надо взять наиболее популярные доклады с JPoint 2017, кратенько пересказать, о чём там речь, почему это круто и зачем нужно лично мне. Каждый из этих докладов заслуживает отдельного разбора, но вначале — краткий обзор первой десятки. Поехали!

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

Этим летом мне посчастливилось попасть на летнюю стажировку в компанию Itseez. Мне было предложено исследовать современные методы, которые позволили бы выделить местоположения объектов на изображении. В основном такие методы опираются на сегментацию, поэтому я начала свою работу со знакомства с этой областью компьютерного зрения.
Сегментация изображения — это разбиение изображения на множество покрывающих его областей. Сегментация применяется во многих областях, например, в производстве для индикации дефектов при сборке деталей, в медицине для первичной обработки снимков, также для составления карт местности по снимкам со спутников. Для тех, кому интересно разобраться, как работают такие алгоритмы, добро пожаловать под кат. Мы рассмотрим несколько методов из библиотеки компьютерного зрения OpenCV.

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


Лабиринт в процессе прохождения.

Предисловие

В последнее время Micro SD карты становятся всё более популярны. По этому поводу появляется всё больше продавцов, готовые на этой почве поживиться обманом и разными уловками на эту тему.
Понадобилась мне как-то Micro SD карта ёмкостью 64ГБ для небольшого проекта на Raspberry Pi. Но когда я стал искать что-то подходящее на eBay, то с удивление обнаружил, что подавляющее число продавцов выставляют откровенные подделки. Даже на Амазоне ситуация была не очень привлекательна в этом плане. На картинке выше все карты являются подделками.

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

Обещаю слайды.

Практика — это когда всё работает, но никто не понимает, как. Теория — когда ничего не работает, но все точно знают, почему. Мы же пришли к сочетанию теории с практикой: ничего не работает — и никто не понимает, почему.

В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок. Статья публикуется с сокращениями, полная версия доступна в нашем блоге на Хабре.

Привет, хабрапользователь! После небольшого перерыва можно опять браться за трехмерную графику. В этот раз мы поговорим о таком алгоритме глобального затенения, как Normal-oriented Hemisphere SSAO. Интересно? Под кат!

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

Программный рендеринг (software rendering) — это процесс построения изображения без помощи GPU. Этот процесс может идти в одном из двух режимов: в реальном времени (вычисление большого числа кадров в секунду — необходимо для интерактивных приложений, например, игр) и в «оффлайн» режиме (при котором время, которое может быть потрачено на вычисление одного кадра, не ограничено настолько строго — вычисления могут длиться часы или даже дни). Я буду рассматривать только режим рендеринга в реальном времени.

У этого подхода существуют как недостатки так и достоинства. Очевидным недостатком является производительность — CPU не в состоянии конкурировать с современными видеокартами в этой области. К достоинствам стоит причислить независимость от видеокарты — именно поэтому он используется как замена аппаратного рендеринга в случаях, когда видеокарта не поддерживает ту или иную возможность (так называемый software fallback). Существуют и проекты, цель которых — полностью заменить аппаратный рендеринг программным, например, WARP, входящий в состав Direct3D 11.

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

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

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

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Готовился я как-то к собеседованию по C# и среди прочего нашел вопрос примерно следующего содержания:

«Как организовать потокобезопасный вызов события в C# с учетом того, что большое количество потоков постоянно подписываются на событие и отписываются от него?»

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

Особо внимательный читатель сможет найти в статье два комикса в стиле xkcd.
(Осторожно, внутри две картинки примерно по 300-400 кб)

Не прошло и года, как я добрался до продолжения статьи про асинхронность. Эта статья развивает идеи той, самой первой статьи про асинхронность [1]. В ней обсуждается достаточно сложная задача, на примере которой будет раскрыта мощь и гибкость использования сопрограмм в различных нетривиальных сценариях. В заключение будут рассмотрены две задачи на состояние гонки (race-condition), а также небольшой, но очень приятный бонус.

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

(пятница)

Обычно развернутое приложение в файловой системе выглядит как-то так:



Совершенно незащищенное от инструментов типа рефлектора или IlSpy, но что если оно станет таким:



По крайней мере легкий ступор хакеру-неофиту обеспечен. Приятно смотрится, и антивирусы не заинтересуются.

Как вы, возможно, знаете в мире Windows для рисования графики часто используется DirectX. В последних версиях (10, 11.x) библиотека серьёзно шагнула вперёд и именно на них построены движки многих современных игр. Кроме того, DirectX используется не только в играх — сам интерфейс ОС Windows тоже с непомню-какой версии (Vista?) рисуется через него, да и казалось-бы не сильно связанные с графикой программы, желая увеличить производительность и плавность зума\скрола переходят на последние версии DirectX. Так некоторое время назад на DirectX11 перешел рендер Google Chrome (вроде бы с версии 36).

Когда-то во времена Windows 95 и Pentium II была такая шутка, что чем медленнее компьютер — тем лучше можно понять работу операционной системы — невооруженным глазом видно в каком порядке прорисовываются элементы окон, обрабатываются события. Сегодня для подобных целей относительно DirectX есть отдельные инструменты — графические отладчики, позволяющие понять, как именно рисуется каждый пиксель каждого кадра, какие операции выполняет движок DirectX, какие ресурсы он использует, насколько быстро и правильно всё работает. Один из таких инструментов — RenderDoc от компании Crytek мы сегодня и рассмотрим. А в качестве примера разберём уже упомянутый выше новый рендер Google Chrome.

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

Одним из недешевых процессов с точки зрения производительности является boxing и unboxing. Напоминалку о том, что это такое, можно найти тут. Недавно я решил посмотреть весь IL код наших проектов и поискать инструкции box и unbox. Нашлось достаточно много участков, boxing'а в которых можно избежать легким движением руки. Все случаи, приводящие к ненужному boxing'у, очевидны, и допускаются по невнимательности в моменты концентрации на функциональности, а не на оптимизации. Я решил выписать наиболее часто встречающиеся случаи, чтобы не забывать о них, а затем автоматизировать их исправление. В данной статье и перечислены эти случаи.

Боб Найстром, программист, проработавший восемь лет в компании Electronic Arts, закончил работу над книгой «Game Programming Patterns». Она доступна бесплатно на сайте gameprogrammingpatterns.com. Писать книгу Боб Найстром начал четыре года назад. Большинство книг, посвящённых программированию игр, говорит он во введении, либо подробно раскрывают какой-то из аспектов создания игры — физический движок, графику, искусственный интеллект, либо описывают процесс создания игры в определённом жанре от начала до конца. Ему очень не хватало книги, рассказывающей о решении типовых задач, возникающих перед программистом, книги достаточно универсальной, не привязанной к жанрам или конкретным подсистемам игр. И поэтому он решил написать такую книгу сам.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Введение

Данную статью я решил написать после прочтения статьи «Массивно-параллельная стабилизация изображения», в которой описывается алгоритм для стабилизации изображения с поворотных камер. Дело в том, что в свое время мной был реализован алгоритм для стабилизации изображения со стационарных камер, который используется в IP-видеосервере MagicBox и некоторых других продуктах компании Синезис, в которой я работаю по настоящее время. Алгоритм получился достаточно удачным по своим скоростным характеристикам. В частности, в нем очень эффективно реализован алгоритм поиска смещения текущего изображения относительно фона. Эта эффективность позволила задействовать основные его элементы (конечно с некоторыми модификациями) для сопровождения объектов, а также для проверки их на неподвижность.

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

Рис. 1 Стабилизация изображения иногда очень полезна.