Так случилось, что я активно использую Delphi в своей работе (программирование по работе, собственные открытые и закрытые проекты) и вот мне понадобилось написать программу, использующую открытую библиотеку компьютерного зрения OpenCV. Что же делать, ведь официально OpenCV использовать в Delphi невозможно, а перебираться на C ради одной программы слишком долго.

Но нет ничего невозможного…

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

От переводчика

Я очень люблю игры компании Blizzard и, наткнувшись недавно на блог одного из из создателей серии Warcraft — Патрика Вайата, решил перевести третью заметку о создании первой части этой замечательной игры. Перевод первых двух (первая, вторая) уже есть на хабре.
Итак, вас ждёт рассказ об источниках финансирования Blizzard, о том, как Стю Роуз устроил дизайнерский переворот, о тумане войны и, самое главное, о впечатлениях автора статьи от самой первой мнопользовательской игры и о её неожиданных итогах.
За всем этим добро пожаловать за хабракат.
Это мой первый перевод, так что я буду рад всем сообщениям об ошибках, замечаниям и исправлениям.

В минувшие выходные в онлайн-игре EVE Online в системе Asakai произошла масштабная битва с участием 3161 боевого корабля.

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

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

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

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.

DivShot — отличный новый инструмент для работы с Twitter Bootstrap. С помощью него создавать прототипы интерфейсов с использованием популярного CSS-фреймворка стало до безобразия просто.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Оригинал: Starting out on Game Programming

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

Вы только что закончили ваш первый курс по С++ и хотите начать делать игры. Кто-то указал вам на этот сайт и вы, возможно, поэкспериментировали немного с руководством. Вы изучили несколько лаконичных примеров, но не нашли руководства о том, как сделать целую игру. И на то есть причина.

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

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

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

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

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

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

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

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

• Нет, тут есть ошибка -> сами гады -> а может все не так и плохо -> ппц -> ладно, давай выкручиваться

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

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

О чем это

Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

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

На самом деле, после пары десятков проектов я пришел к выводу, что все это — не более чем заблуждения, и чудеса происходят только в книгах авторов, которые делают на своих бестселлерах миллионы. Или в головах консультантов, которые делают деньги, продавая вам фуфло в виде Agile, KPI и прочих умных слов.

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.

Спустя 7 лет разработки увидела свет первая мажорная версия Warsow. Warsow — это атипичный для OpenSource проект с рядом особенностей, и вот почему:

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

• http://www.youtube.com/watch?v=dqHmp_kMz-U — Дуэль
• http://www.youtube.com/watch?v=eqlPbtO3rQY — Дуэль
• http://www.youtube.com/watch?v=zx7xFJiBGZQ — Схватка, >2 роботов, каждый за себя
• http://www.youtube.com/watch?v=EJPskFGvGi8 — Схватка, стоит обратить внимание на робота Portia (бирюзовый) — это один из лучших бойцов в этой категории

В последнее время различные системы онлайн обучения, от LinguaLeo и до Coursera и Udacity, активно набирают все большую популярность. В этом посте мне бы хотелось рассказать о еще одном сервисе для обучения иностранным языкам, Duolingo, обзора которого я еще не встречал на хабре.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

Сегодня пришла рассылка с Kickstarter «Projects We Love». Я решил посмотреть, что нового появилось и меня сразу привлек ярлычок Open-source. Я перешел по ссылке почитать, что такого интересного и нового предлагает автор проекта и мне понравилось. Решил поделиться с хабром.

Light Table

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

Уже давно в воздухе витают идеи, что мы можем сделать IDE лучше и удобнее. Какие же это идеи?

• Вы не должны нигде искать документацию и тратить на это время
• Файловая структура — не лучшее представление для кода
• Редактирование должно быть доступно где угодно и редактор должен показывать не только код
• При любом изменении мы должны видеть результат мгновенно
• Мы должны видеть больше информации о связанных кусках кода

Давайте посмотрим как эти идеи воплощает Light Table.

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

По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.



С этой темой я уже выступал на конференции SQADays, но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.

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

Я хочу рассказать вам о том, что же под капотом у железных монстров из знаменитой игры Battle City (в простонародье «Танчики») с не менее знаменитой приставки Nintendo Entertainment System (сокращённо NES, в России более известен её китайский клон «Dendy»). Мне в своё время эта информация показалась довольно любопытной — надеюсь, такой же она покажется и вам.