Детальный взгляд на логирование переключение контекста с помощью Event Tracing API для Windows.

В ответ на пост прошлой недели, я получил следущее электронное письмо:

Может быть, я немножко опоздал с вопросом по поводу Вашего недавнего поста, но, на всякий случай, спрошу: Вы имеете какие-либо методы (стратегии) работы с внешней библиотекой, от которой Вы не можете избавиться, и которая нарушает некоторые (или все) принципы написания дизайна API (скорее всего, имеются в виду принципы, рекомендации, которые описаны в предыдущей статье автора. Прим. перев.)? Может, есть какие-то истории? Это расплывчатый вопрос, но я просто спрашиваю о любом опыте (как пользователя) использования API, который действительно запомнился.

— Michael Bartnett

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

Наверное, это была бы неплохая статья в цикле еженедельного разбора плохих API. Но, поскольку у меня нет времени на что-то подобное и есть возможность разобрать только один API, то возникает наиболее ВАЖНЫЙ вопрос — какой именно API я должен выбрать?

Event Tracing API для Windows

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

Привет, Хабр!

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

Часто первое знакомство с линейной алгеброй выглядит как-то так:



Не очень вдохновляет, правда? Сразу возникает два вопроса: откуда это все взялось и зачем оно нужно.

Начнем с практики

Когда я занимался вычислительной гидродинамикой (CFD), один из коллег говорил: «Мы не решаем уравнения Навье-Стокса. Мы обращаем матрицы.» И действительно, линейная алгебра — «рабочая лошадка» вычислительной математики:

Разработчик Бен Фрейн (Ben Frain) однажды заметил: «Писать CSS-код легко. Масшабировать и поддерживать его — нет».

К счастью, на просторах интернета можно найти множество решений этой проблемы. В данной статье рассмотрены основные киты структуры CSS-кода, а также интересные рыбы/млекопитающие поменьше.

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

Итак, начнем.

Предисловие

Я уже долгое время ничего не исследую, так сказать ушел на покой. Но тут мне на глаза попалась очередная поделка немало известного в определенных кругах PE_Kill'a. Т.к. мне довелось решать его предыдущую поделку в рамках CRACKL@B Contest 2010, которая в свою очередь была довольно интересна, я решил взглянуть на его новое «детище».

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

Всем привет. Многие знают об этой замечательной игре — LIMBO! Вы даже наверняка покупали ее в Стиме, или качали с торрентов…
Я тоже ее купил когда-то (что и вам советую!), и прошел). Но, как всегда, мне было этого мало, и я, из спортивного интереса, решил изучить ее защиту. Так и появился кейген к игре LIMBO.

«Кто нам мешает, тот нам поможет»
к/ф «Кавказская пленница»

Телевизор в качестве монитора?

В последние годы все более популярным становится использование телевизора в качестве домашнего компьютерного монитора.
И действительно — если еще несколько лет назад типичным для компьютерных мониторов Full HD разрешением (1920x1080) могли похвастаться лишь телевизоры с диагональю 40" и более, слишком большие для настольного монитора, то сейчас нетрудно найти телевизор с Full HD разрешением и с вполне «мониторной» диагональю 32" и меньше. Соответственно и размер пикселя при этом получается близким к «типовому» для настольных мониторов 0,28 мм ± 10% (ну, может быть чуть больше). А если кому-то такой пиксель покажется великоват, то с появлением доступных по цене бытовых телевизоров с разрешением 4k Ultra HD (3840x2160) размер пикселя вполне может конкурировать и с Retina.
К тому же широко распространенные в бытовых телевизорах IPS матрицы по компьютерным меркам считаются весьма «продвинутыми», и ими обычно оснащаются весьма дорогие «профессиональные» мониторы.
Казалось бы вот оно, идеальное решение для экономного домашнего пользователя — купить на грош пятаков небольшой (по телевизионным меркам) относительно недорогой 26"-37" бытовой телевизор с Full HD или Ultra HD разрешением, и в результате получить «компьютерный монитор» с большим (по компьютерным меркам) «профессиональным» IPS дисплеем, который к тому же без дополнительных вложений может быть использован и по прямому «телевизионному» назначению (что для дома тоже немаловажно!).
Однако иной раз результатом такого приобретения становится полное разочарование: компьютерная картинка на экране телевизора оказывается намного хуже, чем на простеньком старом мониторе, вместо которого этот телевизор собственно и приобретался.
Причин этого может быть множество, начиная от несоответствия разрешения соединяющего компьютер с телевизором видеоинтерфейса разрешению телевизионной матрицы, способности телевизора выводить картинку «пиксель-в-пиксель», настроек видеокарты (в частности, Overscan), настроек самого телевизора (например, резкости), проблем с кабелем, и так далее.
В данной статье мы рассмотрим только одну из возможных причин, а именно способность видеоинтерфейса, которым подключен телевизор или монитор к компьютеру, передать полное цветовое разрешение 4:4:4.

Для начала собственно тест:

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

От переводчика: когда я начал разбираться с MVC-фреймворками для фронт-энда, каким-то чудом попалась на глаза эта статья Henrik Joreteg. Сейчас дошли руки перевести ее для Хабра, тем более, что об AmpersandJS на Хабре вообще не слышно. Попробую организовать цикл статей по этому инструменту ребят из &yet, мне кажется, он достоин внимания.



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

Angular.js

за

1. очень легко начать использовать. можно просто вставить тег script, добавить немного ng- атрибутов в ваше приложение, и вы волшебным образом получаете нужное вам поведение
2. Angular хорошо поддерживается его основной командой разработчиков, многие из которых работают в Гугле на постоянной основе
3. большая аудитория/сообщество

Как известно, физики давно пытаются найти Теорию Всего, в рамках которой можно было бы объяснять все известные взаимодействия в природе. Склонность к обобщениям присуща не только физикам, но и математикам, и программистам. Способность меньшим количеством сущностей объяснять и предсказывать большой спектр явлений очень ценна. Для программистов в роли теорий выступают различные API и фреймворки. Некоторые из них решают узкоспециализированные проблемы, а какие-то претендуют на роль универсальных теорий. Примером последних может выступать Qt — универсальный фреймворк, предназначенный, в основном, для разработки GUI.

Далее я расскажу, что мне не нравится в Qt и как его можно сделать ещё более универсальным, мощным и удобным для работы.

Демо-видео (лучше смотреть в HD):

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

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

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Вот что я бы рассказал себе о стартапах, попади я в прошлое на пять лет назад, когда только начинал. По сути это то, чему я научился за прошедшее время. И уж точно это никакие не рекомендации или советы, а «ты» здесь обращено к себе самому, так что читайте как «я». Стиль изложения вольный (прим. переводчика — как и стиль перевода).

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

2. Над этой же идеей прямо сейчас кто-то уже работает. И, в общем-то, это не так плохо.

3. Никогда не подписывай NDA, пока не услышишь о чём вообще речь.

4. Нравится тебе это или нет, но большинство социальных связей в Лондоне основаны на выпивке. Смирись и прими, сумев избежать постоянного похмелья.

5. Люди, которые действительно чего-то добились — это не те, кто постоянно бухает.

6. Линейный рост может быть хуже, чем вообще никакого роста.

7. Большинство людей, которые говорят о скором провале, этим вообще не занимаются.

8. Легко обманывать себя, будто ты «заботишься об интересах пользователей», хотя на самом деле ты пытаешься найти способ заставить их согласиться с тем, над чем ты сам хочешь работать.

Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

Если вы когда-либо делали хелп или мануал для своего приложения, наверняка вы отметили, как неожиданно много времени и сил занимает создание скриншотов.

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

В этой статье я расскажу, как правильно делать скриншоты, почему это не просто “два клика” и какие подводные камни встречаются на пути неопытного скриншотера. Рассматривайте ее как чеклист или список практических советов для тех, кто документирует ПО. Надеюсь, это поможет вам избежать разочарований и порадовать юзеров красочными понятными картинками.

— Теория о системе координат (правосторонней и левосторонней)
— Теория правильного создания 3d моделей в blender
— Быстрый экспорт файлов из Blender в Unity3d.
— Как правильно сопоставить масштабы модели в Blender и Unity.
— Экспорт с правильной ориентацией модели
— Почему количество вершин по-разному отображается в Unity и Blender?

Скрипты для автоматического экспорта из Blender в Unity3d (Ссылку предоставил пользователь darkfrei )

Современные компиляторы очень хорошо умеют оптимизировать код. Они удаляют никогда не выполняющиеся условные переходы, вычисляют константные выражения, избавляются от бессмысленных арифметических действий (умножение на 1, сложение с 0). Они оперируют данными, известными на момент компиляции.
В момент выполнения информации об обрабатываемых данных гораздо больше. На её основании можно выполнить дополнительные оптимизации и ускорить работу программы.
Оптимизированный для частного случая алгоритм всегда работает быстрее универсального (по крайней мере, не медленнее).
Что если для каждого набора входных данных генерировать оптимальный для обработки этих данных алгоритм?
Очевидно, часть времени выполнения уйдёт на оптимизацию, но если оптимизированный код выполняется часто, затраты окупятся с лихвой.
Как же технически это сделать? Довольно просто — в программу включается мини-компилятор, генерирующий необходимый код. Идея не нова, технология называется “компиляция времени исполнения” или JIT-компиляция. Ключевую роль JIT-компиляция играет в виртуальных машинах и интерпретаторах языков программирования. Часто используемые участки кода (или байт-кода) преобразуются в машинные команды, что позволяет сильно повысить производительность.
Java, Python, C#, JavaScript, Flash ActionScript — неполный (совсем неполный) список языков, в которых это используется. Я предлагаю решить конкретную задачу с использованием этой технологии и посмотреть, что получится.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

Сначала мы познакомимся с udev и научимся с его помощью исследовать установленные в компьютере устройства прямо во время загрузки: в качестве примера будем автоматически выбирать настройки видеокарт для Xorg. Затем решим задачу работы с одним образом на десятках компьютеров одновременно путём внедрения собственного обработчика в initramfs, а заодно оптимизируем систему для сетевой загрузки. Чтобы дополнительно уменьшить время загрузки и снизить нагрузку на сеть попробуем NFS заменить на NBD, и помочь TFTP с помощью HTTP. В конце вернёмся в начало — к загрузочному серверу, который также переведём в режим «только для чтения».



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

Начало смотрите здесь:
Первоначальная настройка сервера
Подготовка образа для загрузки по сети

Определения препроцессора (preprocessor definitions) часто используются в С++ проектах для условной компиляции выбранных участков кода, например, платформозависимых и т.п. В этой статье будут рассмотрены, видимо, единственные (но крайне сложные в отладке) грабли, на которые можно наступить при проставлении #define-ов через флаги компилятора.

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

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.

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