Решение задачи онлайн-вещания с IP-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?

tmux — это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как screen, только лучше (в первую очередь потому, что использует модель клиент—сервер).



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

Привет, %username%!

Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

Здравствуйте, уважаемое сообщество! Думаю, многим знакома такая структура данных как суффиксное дерево. На Хабре уже было описание как его построить и зачем. Если вкратце, то оно нужно тогда, когда надо много раз искать какие-то произвольные образцы X_i в заранее заданном тексте A, а строится такое дерево мучительно с помощью алгоритма Укконена (есть и другие варианты, но они предполагают еще большее количество страданий). Общее наблюдение при работе с алгоритмами таково, что деревья — это, конечно, хорошо, но на практике их лучше избегать из за серьезных оверхэдов по памяти и не очень оптимального (с точки зрения эффективности оперирования данными компьютером) расположения. Кроме того, именно в таком дереве есть еще более существенная неприятность, а именно алфавитнозависимость структуры. Для решения этих проблем был придуман суффиксный массив. О том как его строить и как использовать и пойдет в этой статье.

Материал статьи предполагает знание понятий суффикса и префикса строки, а также знание того, как работает бинарный поиск. Надо также представлять, что такое стабильная сортировка и поразрядная сортировка, а также понимание, что имеется ввиду под стабильной сортировкой подсчетом. Для некоторых частей нам понадобится знание задачи о минимуме на отрезке — Range Minimum Query (RMQ). Ну, в общем, вас предупредили: никто не говорил, что будет просто.

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

С некоторой натяжкой именно так работает вращение с помощью углов Эйлера. Немного непредсказуемо и неудобно, не правда ли? Углы Эйлера имеют несколько недостатков, но есть одно особенно нехорошее свойство из-за которого вы не захотите с ними связываться. Его имя — Gimbal lock.

В русском языке gimbal lock называют по-разному: шарнирный замок, блокировка осей, складывание рамок. К сожалению, по запросам в поисковике с такими ключевыми словами выдаётся много мусора, а статья в Википедии оставляет желать лучшего, поэтому я сам расскажу вам об этом феномене и предложу как с ним бороться.

Внимание! Заходя под кат вы подвергаетесь риску поломать голову.

Отгадайте загадку: в четырёх измерениях сидит и комплексными числами воротит?

Подсказка: это вектор со скаляром. И вещественная матрица. И придумал его Гамильтон.

Не помогло? Ну что вы, это же элементарно! Это кватернион! Кватернионы используют для записи вращений в робототехнике, игровых движках, ПО для моделирования и вообще везде, где не нужны проблемы с углами Эйлера или матрицами. Если вас испугала путаница выше с разными представлениями кватерниона, то можете быть спокойны. Кватернионы очень просты в использовании и их внутреннее строение может понадобиться только в очень редких случаях, где нужна тонкая оптимизация. В остальное время с помощью кватернионов можно крутить всё что угодно и как угодно, и оно будет плавно и красиво интерполироваться без шарнирных замков.

В данной статье я расскажу об алгоритме смешивания текстур, который позволяет привести внешний вид ландшафта ближе к естественному. Этот алгоритм легко может быть использован как в шейдерах 3D игр, так и в 2D играх.

Статья рассчитана на начинающих разработчиков игр.

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

Обычно, самый лучший ответ на этот вопрос – «Когда как». Вот только подобный ответ мало кого устраивает, поэтому после него мне приходится устраивать самый настоящий допрос.

Заказ

Одним прекрасным летним днём 2010 года у меня зазвонил телефон.
Это был он. Заказ, который ты обычно ждешь, разгребая горы рутины.
«Требуется встроить компьютер в литой автомобильный диск».


Это звучало как вызов.
Такое спрашивают не каждый день. Я, ни секунды не раздумывая, согласился взяться за работу.
А потом заказчик пропал. Он просто больше не звонил мне. У меня был его номер, но я никогда не навязываюсь, поэтому все радостные переживания, связанные с предстоящей работой над интересным проектом тихо улеглись и забылись.
Прошел год.
Звонит заказчик. Оказывается, он потерял мой номер. И спустя год поисков – нашел!
И закипела работа!

Для многих из нас Super Mario Brothers была первой игрой, которая по-настоящему завораживала своим игровым процессом.
Интуитивное управление SMB и великолепный дизайн уровней от Nintendo заставляли проводить часы напролет в виртуальной вселенной сантехника и его напарника.

В этом чудесном туториале от Джейкоба Гандерсена мы создадим собственный платформер; но, так как главным героем будет Коала, мы назовем нашу игру «Super Koalio Brothers!» ;]
Также, чтобы упростить механику, мы забудем о движущихся врагах. Вместо них мы будем использовать шипованные блоки, встроенные в пол. Это позволит нам полностью сконцентрироваться на сердце платформера — физическом движке.

Внимание! Под катом невероятное количество переведенного текста, картинок, кода (код не переведен) и руководство по созданию собственного физического движка!

Зачем?

Вообще, идея этого поста пришла мне в голову в тот самый момент, когда я, не имея до этого за плечами полноценного опыта фриланса, решил всерьез освоить oDesk. Да, если кто не знает, oDesk — это одна из крупнейших в мире фриланс-бирж. Итак, дело было в июле этого года. Официальной работы к тому времени у меня уже полгода как не было, все подработки закончились, новых серьезных заказов не предвиделось, и oDesk представлялся мне весьма перспективным вариантом. Аккаунт, как водится, был зарегистрирован «про запас» еще за год до того, но висел все это время без дела, поэтому начинать нужно было с нуля. При этом я был почти уверен, что руководство, хотя бы самое краткое, на тему, как и с чего начинать, я где-нибудь (уж на Хабре-то точно!) да найду.
Возможно, я плохо искал. Однако все, что мне попалось по теме, сводилось только к тому, что не нужно сразу загибать цены, лучше начинать с небольших. Примерная цитата: «начинайте с $10 в час, со временем, дорастете и до $15». Дорастать до $15, да еще и со временем, мне категорически не хотелось, я был уверен, что можно зарабатывать значительно больше. Да и кроме того, меня волновало огромное количество вопросов. Как заполнять профиль? На какие проекты откликаться? Как составлять cover letter? Как, черт побери, получить этот первый заказ, когда все тебе отказывают?
В тот момент я решил, что если все у меня получится, обязательно напишу то самое руководство для новичков, которого я не нашел.

Ральф вошел в помещение ангара №1 в 8:30 утра, как делал это ежедневно уже несколько лет. Его взгляд сразу же устремился к центру зала, где на постаменте, окруженный множеством приборов и паутиной кабелей, находился смысл его работы. Собственно говоря, не только его — миллионов людей по всему миру. Первый инопланетный корабль. Полтора десятилетия назад он совершил аварийную посадку и был частично поврежден, оставив, однако, весьма много материала для изучения. Настоящим чудом стало то, что политики и учёные после этого события не переругались, а смогли организовать эффективное изучение свалившегося с небес подарка. На реверс-инжиниринг корабля были брошены лучшие умы планеты. Ральф, возглавляющий группу изучения приборов связи, стоял в ангаре и в который раз любовался стремительной, похожей на стрелу в полёте, формой корабля. Он вспоминал всё, что случилось за последние годы.

Я хотел написать статью про линейную регрессию, но потом подумал, да ну её, лучше куплю квартиру. И пошёл искать, что предлагают. А предлагают, как оказалось, много чего. В подходящий мне ценовой диапозон попало больше 500 квартир. И что, мне теперь все это просматривать? Ну нееет, программист я в конце концов или не программист. Надо это дело как-то автоматизировать.

Перевод статьи The MediaWiki parser, uncovered.

Актуальность перевода статьи 2009 года в том, что, во-первых, костяк парсера с тех пор существенно не поменялся, и во-вторых, с ним приходится ежедневно сталкиваться тем, кто пишет расширения для Mediawiki, на котором крутятся их корпоративные сайты.

Парсер Mediawiki — фундаментальная часть кода движка Mediawiki. Без него вы бы не смогли вставлять в свои статьи Википедии различные метки: секции, ссылки или картинки. Вы даже не смогли бы увидеть или быстро изменить разметку других статей. Вики-разметка достаточно гибка, чтобы дать возможность одинаково легко писать статьи как новичкам, так и HTML-экспертам. Из-за этого код парсера несколько сложноват, и с годами проходил через множество попыток его улучшить. Тем не менее, даже сегодня он все еще достаточно быстро работает для Википедии, одного из самых больших веб-сайтов в мире. Давайте взглянем на внутренности этого ценного (но чуть-чуть заумного) куска кода.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Вдохновившись статьей «У прозрачных пикселей тоже есть чувства или артефакты png'шек с прозрачностью», решил рассказать еще о некоторых проблемах, которые могут возникнуть при разработке 2D-игры.

В этой статье я хотел бы рассказать о нетривиальных проблемах, с которыми мне пришлось столкнуться при разработке 2D-игр, связанных с фильтрацией текстур.

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

http://pyxeledit.com/



Когда я полгода или чуть больше назад решил ради разнообразия попробовать Flixel и сделать свой платформер, то меня сначало удивило, а потом начало злить отсутствие нормального редактора тайлов. С платформером и флешем я уже наигрался, но наткнувшись на бету не могу не поделиться с хабрасообществом.
Пара роликов c использованием под катом.

Эксклюзивно для Хабра.



(кликабельно)

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

1. Поделиться со всеми интересным алгоритмом и его реализацией на С++ (стандарт С++11);
2. Узнать, есть ли у данного алгоритма название и/или формальное описание;