Не так давно на Хабре появилась прекрасная статья Оптимизация сборки мусора в высоконагруженном .NET сервисе. Эта статья очень интересна тем, что авторы, вооружившись теорией сделали ранее невозможное: оптимизировали свое приложение, используя знания о работе GC. И если ранее мы не имели ни малейшего понятия, как этот самый GC работает, то теперь он нам представлен на блюдечке стараниями Конрада Кокоса в его книге Pro .NET Memory Management. Какие выводы почерпнул для себя я? Давайте составим список проблемных областей и подумаем, как их можно решить.

На недавно прошедшем семинаре CLRium #5: Garbage Collector мы проговорили про GC весь день. Однако, один доклад я решил опубликовать с текстовой расшифровкой. Это доклад про выводы относительно оптимизации приложений.

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

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

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

Я уже сбился со счёта часов, которые я потратил на то, чтобы сделать “небольшую коробочку” и вдруг я поймал себя на мысли, что я очень зауважал инженеров — людей, который умеют и могут проектировать и создавать новые вещи. В голове сразу нахлынули воспоминания об устройствах, который я разбирал в детстве (да и не только). Эти забавные ситуации, когда при откручивании последнего болтика, как чёрт из табакерки, вылетало несколько мелких пружинок и деталек, которые было совершенно невозможно упаковать обратно.

Однажды я решил сделать небольшое устройство (“Security Access Tuner” из игры Alien: Isolation) — контроллер, экран, пара элементов управления, да упаковать это всё в небольшой корпус, который планировалось напечатать на 3d принтере. Тогда я ещё и подумать не мог, сколько же времени потребуется, чтобы все эти мелочи собрались в одно целое…

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Привет! Я три года назад читал в детском лагере лекцию про социнжиниринг, троллил детей и немного бесил вожатых. В итоге испытуемые спросили, что почитать. Мой дежурный ответ про две книги Митника и две книги Чалдини, вроде, убедителен, но только для примерно восьмиклассника и старше. Если младше — то надо сильно чесать голову.

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

Предисловие

Не так давно пришлось поработать с упрощением полигональной цепи (процесс, позволяющий уменьшить число точек полилинии). В целом, данный тип задач очень распространен при обработке векторной графики и при построении карт. В качестве примера можно взять цепь, несколько точек которой попадают в один и тот же пиксель – очевидно, что все эти точки можно упростить в одну. Некоторое время назад я практически ничего не знал об этом от слова «совсем», в связи с чем, пришлось в быстром темпе восполнять необходимый багаж знаний по этой теме. Но каково было мое удивление, когда в интернете я не нашел достаточно полных руководств по этому вопросу… Мне приходилось отрывками искать информацию с совершенно разных источников и, после проведенного анализа, выстраивать все в общую картину. Занятие не из самых приятных, если честно. Поэтому мне хотелось бы написать цикл статей, посвященных алгоритмам упрощения полигональной цепи. Как раз-таки начать я решил с наиболее популярного алгоритма Дугласа-Пекера.

Введение

---

«Что получится, если мы заменим числа с плавающей запятой на рациональные числа и попытаемся отрендерить изображение?»

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

Это зародило во мне мысль — если допустить, что все входящие данные рендерера (координаты вершин, 3D-преобразования и т.д.) были бы заданы как рациональные числа, то создавали бы все операции, от создания луча, обхода ускоряющей структуры и до пересечения лучей с треугольниками только рациональные числа? Если это было бы так, то мы бы смогли выполнять проверку копланарности совершенно точно! Возможно, вы зададитесь вопросом, почему 3D-сцена, выраженная в рациональных числах должна давать результаты тоже только в рациональных числах…


Простая сцена, трассировка пути в которой выполнена рациональной арифметикой. Здесь используется система чисел «с плавающей чертой дроби», а не числа с плавающей запятой.

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

Несколько замечательных особенностей украинского языка.

1. Звательный падеж.

Эта милая сердцу категория была в общем прародителе всех славянских языков, но сейчас осталась рудиментарно. Хотя она и понятна носителю современного русского, возьмите обращение «Друже!». Звательный падеж знаком нам из Библии («Отче наш!», «Врачу, исцелися сам!»), что неудивительно, так как церковнославянский — солунский диалект староболгарского.
Примеры:

Введение

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

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

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

Небольшая предыстория

Всё это началось, когда я пытался воссоздать игру Chip's Challenge на Linux.

Изначально Chip's Challenge была выпущена в 1989 году для ныне забытой портативной консоли Atari Lynx. Для того времени Atari Lynx была впечатляющей машиной, но она вышла в одно время с Nintendo Game Boy, которая в конце концов захватила рынок.

Chip's Challenge — это игра-головоломка с видом сверху и тайловой картой. Как и в большинстве таких игр, цель каждого уровня заключается в том, чтобы добраться до выхода. В большей части уровней выход охраняется разъёмом для чипа, который можно миновать, только собрав определённое количество компьютерных чипов.

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



Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

Персонаж — это личность. Без истории нет индивидуальности. Каждый хороший персонаж начинается с истории, а дизайн персонажа должен рассказать эту историю.

В своей предыдущей статье How To Make Low Poly Look Good я говорил, что главная цель низкополигонального (low poly) дизайна — донести сообщение через наименьшее количество форм.

Это особенно справедливо, когда вы создаёте низкополигонального персонажа. Нужно рассказать историю, использовав как можно меньше форм.

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

---

Я буду работать в Blender. В Maya, Max и других 3D-редакторах есть похожие инструменты, так что не беспокойтесь об этом.

Assembler – мой любимый язык, … но жизнь так коротка.

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

Зная себя, я уверен, что игра едва получит своё воплощение, но возможно кого-то из общественности заинтересуют мои наработки на этом тернистом пути. И так приступим.

В нашем блоге на Хабре мы публикуем не только рассказы о разработках сообщества Университета ИТМО, но и фотоэксурсии — например, по нашей лаборатории робототехники, лаборатории киберфизических систем и DIY-коворкингу Фаблаб.

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

Введение

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

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

Предмет исследования

Продолжаем изучать код плагина к Visual Studio Atomineer Pro Documentation (далее APD). Давайте познакомимся поближе с инструментом и с его возможностями.

Несколько недель назад я, развлечения ради, собрал простенькую роботизированную руку (а-ля манипулятор) и решил прикрутить к ней управление со смартфона через Bluetooth. Опыта в разработке нативных мобильных приложений у меня пока нет, с Apache Cordova я уже знаком, а вот задействовать Web Bluetooth API было бы интересно, приправив фишками Progressive Web Apps.


Картинка Для Привлечения Внимания, ведущая под кат

На первый взгляд может показаться, что статей по ключевым словам достаточно: есть спецификация Web Bluetooth, подробная статья в блоге Google Developers с примерами, есть подробный разбор Bluetooth Low Energy, примеры реверс-инжиниринга протоколов различных BLE устройств и даже моргания «умными» лампочками и получения данных от фитнес-браслетов прямо из браузера — что может пойти не так?

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

Такая история со мной приключилась в момент обзора с коллегой r3s потребительской беспроводной Bluetooth-акустики Klipsch KMC 3. Я столкнулся с ситуацией, когда «беспроводной» аудиопоток начинал безбожно прерываться, стоило лишь мне расположить источник звука у себя за спиной. Пищи для размышлений мне подкинула другая Bluetooth-аудиосистема, которая в тех же условиях вела себя куда лучше. Такая простая проблема выродилась в нырок с головой во внутренности протокола Bluetooth и детали передачи аудио с его помощью.

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

Добрый день.

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

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

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

Классификация лабиринтов

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

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