Вы когда нибудь выполняли массовое переименовывание файлов, или какую-нибудь другую, кажущуюся банально лёгкой, но рутинную задачу? Ни разу не создавали bat'ники, но знаете C#?

Находясь в похожей ситуации, в течение 15 минут было создано довольно простое приложение которое похоже на консоль, но которое понимает C#.

В этой статье я хочу поделиться с вами нашим опытом разработки мобильной кросс-платформенной (iOS/Android) игры.

Игру мы писали на Unity, а сама графика — спрайтовая. Но многое из сказанного ниже будет справедливо также и для других кросс-платформенных движков, а так же — для полноценного 3D.

Начну я свой рассказ с заблуждения.

Миф о кросс-платформенности.

Когда мы с командой начинали разработку этого проекта на большом и очень кросс-платформенном движке Unity (который также поддерживает Win, Mac, XBox, PS3, PSP, и т.п.) — то мы надеялись на то, что Unity возьмет всю заботу о кросс-платформенности на себя, а наша задача будет только жать «publish» под разные платформы и пить кофе.

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

Но не все так просто.

В процессе разботы над одной задачей в проекте Карты Mail.Ru возникла необходимость чтения формата WKB. Конечно, можно было воспользоваться GDAL, но нужно было только чтение, а все остальные возможности были излишни. Так и родился этот небольшой велосипед.
Хочу сразу предупредить, что функциональность реализована только в необходимых рамках и поддерживаются только базовые типы, такие как:

• точка
• линия
• полигон
• мультилиния
• мультиполигон

Не поддерживается перекодировка порядка следования байт в слове. А так — бери и пользуйся.

Я бы хотел посвятить статью обзору API, предоставляемых разными ОС для слежения за изменениями в директории. Статья появилась как результат моей работы над демонами слежения за изменениями для утилиты dklab_realsync (статья на хабре, github репозиторий) и своей собственной, которую я пока что не хочу анонсировать.

Введение.

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

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

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

Так как у меня была одна неделя до моего следующего контракта, я решил закончить мой цикл статей id. После Doom,Doom Iphone, Quake1, Quake2, Wolfenstein iPhone и Doom3, я решил изучить код, который я еще не рассматривал: idTech3 — 3D движок Quake III и Quake Live.

Введение

Бывают ситуации, когда очень хочется использовать любимый редактор, но под рукой нету *nix операционных систем, либо разработка ведётся на Windows.

Первое что приходит на ум — использование Windows версии gVim, но в этом случае возникает куча проблем с установкой плагинов, переносом конфигов и адаптации всего и вся. Что-то не будет компилироваться без бубна (например Ctrl-p), а что-то падать во время работы.

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

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

Недавно нам удалось пообщаться с великим Монти — Майклом Видениусом, автором оригинальной версии открытой СУБД MySQL, который в настоящее время работает над ее ответвлением, MariaDB. (Кстати, обе эти базы поддерживаются в Jelastic.)

Как известно, мир производит и обрабатывает все больше данных (так называемый феномен «Big Data»). Общепринято мнение, что данных теперь так много, что обрабатывать их с помощью традиционных баз данных и программных методов трудно или невозможно. Это вызвало волну нереляционных баз данных (NoSQL), в которых упор делается на высокую масштабируемость. Эксперт в области баз данных, Монти, поделился с нами своими мыслями о текущем и будущем состоянии SQL, NoSQL и Big Data. Некоторые его ответы были несколько неожиданными, так что мы с радостью приводим здесь русский перевод расшифровки нашей беседы:

В определенный момент мне стало некомфортно использовать стандартный контрол WebBrowser, предлагаемый Visual Studio.
Причин было несколько:
1. Использовался IE-движок, что само по себе уже сильный аргумент.
2. Кривая работа с JS.
3. Отсутствие масштабирования.
4. Если запустить на машине, где стоит IE6, то все его «достоинства» переносятся на приложение.

В итоге был начат поиск альтернативных решений.
Было рассмотрено 2 SDK. xulrunner(Mozilla) и Awesomium(Chrome)

Подключение обоих происходит примерно одинаково, но на всякий случай опишу оба.

Фильтр Калмана — это, наверное, самый популярный алгоритм фильтрации, используемый во многих областях науки и техники. Благодаря своей простоте и эффективности его можно встретить в GPS-приемниках, обработчиках показаний датчиков, при реализации систем управления и т.д.

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

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

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

• проективная геометрия и однородные координаты
• модель камеры
• эпиполярная геометрия (epiporal geomerty), фундаментальная и существенная матрицы (fundamental matrix, essential matrix)
• триангуляция стереопары точек
• карта глубины(depth map), карта смещений(disparity map) и идея, лежащая в основе ее вычисления

Практически весь материал статьи основан на книге "Multiple View Geometry in Computer Vision" by Hartley, R. I. and Zisserman, A., а раздел про построение карты глубины описан на основе материала из "Learning OpenCV" by Gary Bradski, Adrian Kaehler.

Для понимания содержимого статьи достаточно иметь общее представление об аналитической геометрии и линейной алгебре: знать, что такое матрица, вектор, скалярное и векторное произведение.

Привет.

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

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

В официальной документации описан способ создания «instance store-backed AMI». Минус такого подхода заключается в том, что готовый образ нужно будет ещё и сконвертировать в «EBS-backed AMI»

О том, как создать свой EBS-backed AMI в облаке Amazon без промежуточных шагов, пойдёт речь в этой статье.

Суть проблемы

Сейчас появляется очень много материала про юнит и нагрузочное тестирования. Все поголовно пишут тесты, код создают исключительно через TDD, используют jmeter/ab. Однако, все тестирование очень тесно связано с тестовыми данными. А их нужно генерировать/писать. Проблема не стоит остро для юнит тестирования — накидал mock, погонял его и забыл. Но как быть с нагрузочным тестированием? Когда мне нужно не 1-2-5-10 объектов, а миллионы?

Большинство (php) разработчиков, которых я встречал, сталкиваясь с задачей нагрузочного тестирования своего кода, создают несколько фикстур руками и насилуют их (ab/jmeter). Полученный результат тестирования не является достоверным, но они об этом не думают. Более продвинутые пишут скрипты для генерации данных, закидывают в БД и после этого уже играются. Похвально, но таких значительно меньше, а сам способ мне не кажется идеальным — другой программист может не разобраться в говнокоде генерилки фикстур (ведь создатель писал это быстро и для утилитарных целей) и рано или поздно все либо пойдут по первому пути, либо начнут писать новую генерилку.

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

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

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

Если мы хотим узнать на сколько тот или иной объект объект сместился по отношению к его же положению на предыдущем кадре за то время, которое прошло между фиксацией кадров, то скорее всего в первую очередь мы вспомним про оптический поток (optical flow). Для нахождения оптического потока можно смело воспользоваться готовой протестированной и оптимизированной реализацией одного из алгоритмов, например, из библиотеки OpenCV. При этом, однако, очень невредно разбираться в теории, поэтому я предлагаю всем заинтересованным заглянуть внутрь одного из популярных и хорошо изученных методов. В этой статье нет кода и практических советов, зато есть формулы и некоторое количество математических выводов.

С течением времени изменяются наши представления о способах взаимодействия с компьютером. На смену «классических» клавиатуры и мыши, в нашу жизнь прочно вошли тачпады и сенсорные экраны. Но это не последняя ступень эволюции для средств ввода информации. С появлением устройств дополненной реальности, например таких, как Google Glass, возникает необходимость в интерфейсах способных гармонично вписываться в данную концепцию. Предпосылки к возникновению таких интерфейсов имеются, так, например, появились такие устройства как Intel Creative Camera, Microsoft Kinect или Leap Motion. Основными управляющими элементами в данных устройствах являются руки пользователя. Поэтому, одной из фундаментальных алгоритмических задач, для взаимодействия с подобными устройствами, является детектирование рук и пальцев пользователя и реконструкция их пространственного расположения.
В данной статье речь пойдет о одном из способов решения задачи детектирования ладоней и пальцев.