Вот уже течение 10 лет компания Metaio GmbH разрабатывает и совершенствует технологии дополненной реальности (ДР) для ПК и мобильных устройств. Одним из результатов этих титанических усилий стал Metaio SDK – набор инструментов для внедрения элементов ДР в приложения и программы, оптимизированный при поддержке и помощи Intel под ее платформы. Набор, между прочим, совершенно бесплатный! Предлагаем вам поближе познакомиться с этим продуктом и посмотреть, как он работает.

Страница проекта на Кикстартер — (Kickstarter link)
Страничка проекта на Фейсбуке — (Facebook link)
Официальный сайт разработчика Kilobite
Твиттер Максима Пашанина Twitter-link
Дебютный трейлер KS кампании Trailer Link

Честно, как на духу, не собирался писать что-либо до завершения еще одного туториала, ибо лучше моей болтовни — хорошая, добрая помощь, вы ясно мне дали это понять (смеется). Но сегодня под вечер увидел эту игру на Kickstarter, и как в случае с SpinTires не удержался. И вовсе не потому, что ее также делают наши соотечественники, и даже не потому, что ролик естественен как пение птиц по утру, но потому, что она… сказочная. И одновременно настоящая. Это не закос (да простят мне подобные формулировки) под ретро, это именно следование заветам, уважение традиций, и одновременно оригинальная подача того чтобы мы знали когда-то и того что мы никак не можем забыть. Предположу, что и не хотим забывать.



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

Ручное тестирование — это кропотливый и порой рутинный процесс. Одной из проблем является то что при внесении изменений в код сложно предсказать какие тесты следует проделать заново, чтобы убедиться что все работает так как следует. Для этого прибегают к регрессионному тестированию и повторному прогону всех тестов. Такие операции требуют много времени. Но если вы разрабатываете свои решения на платформе .NET то у вас есть шанс значительно снизить трудозатраты тестировщиков, потому что вы будете точно знать, какие тесты следует провести а какие нет, так как изменения в коде не затронули их поведение. Звучит заманчиво?

Все мы ходили/ходим на собеседования. Каждый раз при подготовке к очередному собеседованию просматриваем основные темы, вспоминаем вопросы, которые нам задавали в предыдущие разы, или вопросы, которые сами задавали. Ниже хочу представить основные вопросы, которые часто (основано на личном опыте) можно получить на собеседовании на должность middle/senior iOS Developer. Так сказать, шпаргалка. Заодно можно проверить свой уровень знания платформы.

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



У меня все работает!

Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.

Итак, вы задумали делать продукт. Не проект, а именно продукт, который через Х месяцев должен появиться в сторах и начать свое движение к звездам. Вы уверены в своих силах и знаниях, а количество новых идей, которые могут превратиться в настоящие киллер-фичи, просто зашкаливает. Самое время сказать себе “стоп!” и разобраться в том, что должно войти в комплект вашей самой первой релизной версии.

После того как вы расписали все характеристики будущего продукта, необходимо определить приоритеты в разработке. Первое желание – ранжировать по сложности реализации. Логично, тем более если ресурс ограничен – нет смысла строить “Титаник”, когда для первого преодоления Рубикона нужна просто шустрая и устойчивая лодка. Следуя заветам customer development, вы в будущем будете только наращивать функционал: главное – в архитектуре не промахнуться.

Итак, делаем шуструю лодку. Но выбор все еще непрост – даже из относительно простых деталей нужно определить тот набор, который и станет вашим release candidate. И здесь вам на помощь придет модель, которую придумал в 70-е годы прошлого века японский ученый Нориаки Кано. На “Хабре” уже был текст об использовании его модели для решения задач UX. Этот подход вполне применим и к продуктовым функциям – ведь они тоже отвечают за эмоциональные реакции потребителей. Кано предположил, что таких реакций бывает пять типов: от полной неприязни до прямо-таки восхищения. Эти типы японец изложил на одном графике, где по вертикальной оси отобразил эмоциональную реакцию пользователя (неприязнь – восхищение), а по горизонтальной – “количественное” значение характеристики (нет – много).

      В мире Arduino существует собственная, написанная на java, IDE, достаточно спартанского вида, без подсветки текста и автодополнения! Главные ее функции — это сборка программы и загрузка. Компиляция осуществляется через avr-gcc, а загрузка в МК через avrdude. После нескольких месяцев использования, решил поискать альтернативу, так как Arduino IDE у меня периодически умудрялось грузить процессор на 100% или просто вылетать! Проверив выдачи поисковика, был маленько разочарован, под linux особо альтернатив нет, кроме консольной ino. Ну что, возможно, консольного клиента нам вполне и хватит, приступим…

Всем привет!
Хочу начать вольный перевод книги «ZeroMQ.Use ZeroMQ and learn how to apply different message patterns». Уверен, что многие захотят разобраться с этой интересной библиотекой.

Содержание

• Глава 1: Приступая к работе
• Глава 2: Знакомство с сокетами
• Глава 3: Использование топологии сокетов
• Глава 4: Дополнительные паттерны

Добро пожаловать в ZeroMQ! Эта глава представляет собой введение в ZeroMQ и дает читателю общее представление о том, что такое система очередей сообщений и, самое главное, что такое ZeroMQ. В этой главе мы поговорим о следующих темах:

• Обзор того, что представляет собой очередь сообщений
• Зачем использовать ZeroMQ и что отличает ее от других технологий работы с очередями сообщений
• Основы клиент/серверной архитектуры
• Рассмотрим первый паттерн: запрос-ответ
• Как мы можем обрабатывать строки в C
• Проверка установленных версий ZeroMQ

Я предыдущих статьях я рассказывал, как мы запускали игру на Google Play и в социальных сетях. Следующей платформой должна была стать iOS, но опять возникли заминки и было принято решение опробовать пока Windows Phone 8. На портирование игры ушло несколько недель, и еще столько же на одобрение в маркете. В статье я расскажу, что мы проделали и что из этого вышло.

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

Основными источниками данных для нас являются международные базы знаний, включающие русскоязычный контент: DBpedia, Freebase и Wikidata. В первую очередь это справочные, лингвистические и энциклопедические данные. Каждый раз когда вам в голову приходит мысль распарсить кусочек википедии или викисловаря — ущипните себя как следует и вспомните о том, что всё, что хранится в категориях, инфобоксах или таблицах, уже распарсено и доступно через API с помощью SPARQL или MQL-интерфейса.

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

Эта статья — первая из цикла Базы знаний. Следите за обновлениями.

• Часть 1 — Введение
• Часть 2 — Freebase: делаем запросы к Google Knowledge Graph
• Часть 3 — Dbpedia — ядро мира Linked Data
• Часть 4 — Wikidata — семантическая википедия

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

Эта статья продолжает цикл статей об игровом движке StalinGrad. В прошлой статье мы насиловали DHTML, а в этой — будем насиловать архитектуру и прототипы.

Кода практически не будет, поэтому, если вы не web разработчик, можете просто почитать про архитектуру и ООП. И таки да — про HTML5 тут снова ничего не будет, только DHTML-хардкор :)



Сразу короткое демо:
Пример 1 — паралельные миры
Пример 2 — один мир с разных камер
Пример 3 — боты
Пример 4 — нянкэт, облака и портальная пушка

Не нашёл на хабре — спешу поделиться. Восхитительное выступление Александра Соловьёва ingspree на конференции JavaScript Frameworks Day 2013. На видео ниже просто набор отрывков из него, желающим посмотреть полностью — сюда.

3. Прототипное наследование

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

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

Пару дней назад я опубликовал и потом внезапно убрал в черновики статью о плане написать про создание своей ОС для архитектуры ARM. Я сделал это, потому что получил много интересных отзывов как на Хабре, так и в G+.

Сегодня я попробую подойти к вопросу с другой стороны, я буду рассказывать о том, как программировать микроконтроллеры ARM на нарастающих по сложности примерах, пока мы не напишем свою ОС или пока мне не надоест. А может, мы перепрыгнем на ковыряние в Contiki, TinyOS, ChibiOS или FreeRTOS, кто знает, их там столько много разных и интересных (а у TinyOS еще и свой язык программирования!).

Итак, почему ARM? Возиться с 8-битными микроконтроллерами хотя и интересно, но скоро надоедает. Кроме того, средства разработки под ARM обкатаны долгим опытом и намного приятнее в работе. При этом, начать мигать светодиодами на каком-то «evaluation board» так же просто, как и на Arduino.

Был как-то проект у меня, который был связан с картой города. И возникла идея, что раз есть карта с маршрутами и соответствующими остановками городского транспорта, то почему бы не сделать поиск пути из пункта А в пункт Б на ней.

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

Где-то около часа или двух я сидел и не мог ничего придумать, а потом появилась идея, что я могу рассматривать маршрут, не как множество остановок, а как 1 точку. И если я сверну маршруты в точку, то я получу очень простой граф.
Идея показалось неплохой, и мне понравилась.

Первое что сделал это запарсил с сайтов маршруты транспорта. Далее принялся за граф.
Это оказалась не сложная задача, берем каждую остановку маршрута и смотрим, нет ли остановок любого другого маршрута в заданном нами радиусе. Радиус взял 600м (в последней версии 400м) – предполагаемое расстояние, которое человек может пройти безболезненно пешком от одной остановки до другой в случае необходимости пересадки. Вероятно, это расстояние можно сократить, скажем, до 200м, так как расстояние от одной остановки до другой на перекрестке не превышает эту дистанцию.

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

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

Качество видео ужас, но как сделать получше я так и не обнаружил.



Усредненное время, затрачиваемое на выполнение шагов:

gpt — 0.009с, найти ближайшие остановки к точке клика
grt — 0.001с, найти кратчайший путь от маршрута к маршруту
apt — 0.0001с, добавляем остановки и точки поворота к нашему маршруту
all — 0.01c, суммарное время выполнения поиска пути

За последний год я имел отношения к записи более 1000 лекций разного уровня сложности и хотел бы поделиться своим опытом в этой части. Это обещанное продолжение статьи Тренды в образовательной среде (памятка для вуза).

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

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

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

Итак, можно выделить следующие типы видеосъёмки лекций:

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

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

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

В "Чертежи в SVG формате. Часть 3 — Черновик стандарта " приведён пример заштриховывания областей и примеры шаблонов штриховки разных материалов из CAD систем. В продолжении рассмотрим рисование размеров.

Перевод статьи If Hemingway wrote JavaScript.

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

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

Так что же такого в JavaScript, что так привлекает многих поклонников литературы? У меня есть несколько дурацких теорий, связанных с выразительным потенциалом ограниченного синтаксиса, но об этом как-нибудь в другой раз. Давайте взглянем на великих писателей: что если бы они писали на JavaScript? Как фанат Хемингуэя со стажем, я бы сказал, что он скорее всего возненавидел бы программирование (и программистов). Но я готов поспорить, что среди всеобщего презрения нашлось бы маленькое теплое местечко для JavaScript, потому что это был бы своего рода его язык. Свободный и обманчиво простой на поверхности, которая скрывает сущность и драму под собой.

Родоначальник всех код ревью

Уважаемые Хабрапользователи!

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

Мы будем крайне признательны за конструктивную критику проекта, а все ценные замечания и пожелания будут внесены в очередную редакцию стандарта. Если такой опыт окажется удачным, то будем представлять на суд уважаемой Хабрааудитории все проекты всех стандартов, проходящих через ТК-234. Текст стандарта под катом.