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

Мы все прекрасно понимаем, что не существует универсальной системы управления проектами, которая бы подходила для всех случаев. Выбор системы целиком и полностью зависит от Ваших нужд. Если вы не нуждаетесь в репозитариях, и для общения Вам достаточно комментариев в тикетах, а работаете Вы над проектром по «гибким» методологиям, то возможно одним из лучших вариантов будет — Pivotal Tracker.

Пост в первую очередь предназначен для тех, кто не знаком с Pivotal Tracker, или тех кто считает его сложным и непонятным.

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

Эта статья является изложением в письменном виде моего личного восприятия программирования и Объектно-ориентированного программирования в частности. Здесь собраны и душевные негодования, и переживания за программистов всего мира. Всё, конечно же, подкреплено исходным кодом.

_{большое разрешение — по клику}

Снова здравствуй, Хабр!

В этом посте я бы хотел рассказать о великолепной программе под названием Nuke от компании The Foundry, которая уже затрагивалась вот в этом посте, но вызвала много вопросов читателей, далеких от 3д графики в общем, и от 3д-композитинга в частности.

Если описать в двух предложениях, то Нюк является мировым стандартом в композитинге и пост-обработке, и был одним из ключевых инструментов в подавляющем большинстве голливудских фильмов с бюджетом, отличным от кустарного.
Да что вообще говорить — Аватар, Трон: Наследие, Трансформеры, Watchmen, Властелины Колец, и большинство остальных голливудских блокбастеров были сделаны именно в Нюке.

Познакомился я с ним примерно три года назад, и сразу же в него влюбился: это одна из самых гениальных программ, что я когда-либо видел — как в плане используемых подходов, так и в плане юзабилити.

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

В процессе написания поста я понял, что все, что я хотел бы описать, просто не уместится ни в один пост, ни в цикл статей. Хоть пост и получился длинным, но это вершина айсберга — в нем описывается чуть менее 0.01% всего, чем хочется поделиться.

Интересно?
Добро пожаловать под кат! Осторожно! Много трафика, Джобса, чайников, и надкусанных НЛО.

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

«Преждевременная оптимизация есть корень всех зол»
Энтони Хоар

Приветствую всех пользователей Хабра!
Данная статья возникла как полезный побочный продукт моих научных изысканий. Буду рад, если идеи, изложенные ниже, покажутся для вас интересными и полезными, а еще лучше, если получат своё применение и дальнейшее развитие в реально существующих проектах.

Производительность программного обеспечения (ПО) является важным аспектом в разработке любого программного продукта. Актуальность вопроса объясняется постоянно возрастающей сложностью и значимостью программных средств. Особое внимание производительности уделяется:

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

Рассматривается библиотека NetworkX предназначенная для создания, манипуляции и изучения структуры, динамики и функционирования сложных сетевых структур.
Рассмотрены основы использования библиотеки в качестве инструмента обучения, прикладного программирования или научных исследований.
Основой для описания библиотеки служат официальные материалы с сайта.
Рассмотрена версия библиотеки 1.5.

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

Вступление окончено, переходим к советам!

Предисловие

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

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

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

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

Они в каждой собственной неудаче видят руку врага. Боже мой, мои сожаления.

А теперь поговорим о правде. Как же так получается, что кто-то постоянно в проблемах, а кто-то постоянно в развитии?

Введение

        Коллега Bo_bda рассказывает о фундаментальных проблемах обработки и анализа изображений. Что же, не могу остаться стороне и не поделиться своими опытом. Сегодня я вам расскажу о такой занимательной штуке, как марковские сети (markov random fields в зарубежной литературе). Данная математическая модель используется при решении практически всех задач обработки графики (тут вам и сегментация, и восстановление изображений, построение стереоизображений, различные вопросы в 3D и много чего еще).
        Внимание! Под катом тонны картинок (в блоге о графике-то, к чему бы это).

LyX — это WYSIWYM процессор документов, который прозрачным образом работает с LaTeX. То есть пользователь создаёт в этом процессоре файлы *.lyx, из которых потом создаются и компилируются *.tex.
Sage — это система компьютерной алгебры, работающая прозрачным образом с другими математическими пакетами. Основной интерфейс — командная строка, при этом используется всё многообразие возможностей python. Также доступен web-интерфейс, который можно опробовать на сайте разработчиков.
Совместное использование этих двух разработок открывает интересные возможности. Например, можно создавать отчёты, в которых вычисления, графики и аналитические выкладки будут выполняться автоматически, почти как в маткаде каком-нибудь, но с наглядной структурой LyX, гибкостью python и возможностями вёрстки LaTeX.

Здравствуйте. В короткой серии постов я постараюсь описать возможности, и подходы работы с одной из наиболее популярной и развивающейся РТОС для микроконтроллеров – FreeRTOS. Я предпологаю базовое знакомство читателя с теорией многозадачности, о которой можно почитать в одном из соседних постов на Хабре или ещё где-то.
Ссылки на остальные части:
FreeRTOS: межпроцессное взаимодействие.
FreeRTOS: мьютексы и критические секции.

Аббревиатура OFDM расшифровывается как Orthogonal frequency-division multiplexing. В русскоязычной литературе встречается несколько различных переводов, несущих, в принципе, один смысл: OFDM — это механизм мультиплексирования (уплотнения) посредством ортогональных поднесущих.

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

Иллюстраций: 18, символов: 27 399, строк кода: 99.

Традиционно поиск проектов фрилансерами и фрилансеров заказчиками происходит на всевозможных фриланс-биржах. Но они как правило имеют существенные недостатки по качеству опубликованных проектов / предложений от фрилансеров.

Возьмем например weblancer.net. Пример проекта который каким-то образом прошел модерацию:



С другой стороны оказывается люди вполне готовы работать с таким бюджетом:



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

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

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

Продолжение

Мало кто из знакомых со словами linux, *bsd не знает о Midnight Commander. Я не слишком ошибусь, если скажу, что все поначалу пользовались им. Отличный инструмент для задач, которые он решает, к тому же доступный на многих платформах. Последнее время проект, ранее развиваемый под крылом gnome.org, получил вторую жизнь. Новый сайт проекта радует темпами развития. Вот только поддержка актуальных версий пакетов в дистрибутивах хромает.

Последнее, что доступно в Debian — 4.7.0.9, и это при том, что совсем недавно вышел 4.7.5.4 в котором есть ряд вкусностей. Проект предоставлял бинарные сборки для RedHat-based систем и не поддерживал таковые для Debian/Ubuntu. Я решил восполнить этот пробел, запустив автоматическую сборочную среду.

Что имеем

Начну с того, что расскажу немного о проекте, в котором работаю и как там все пишется. Может не у одних нас так…

Проект представляет из себя CRM систему, разрабатываемую специально для клиентов одного сегмента бизнеса. Проекту лет 6 и команда разработчиков состоит из 10 человек. Язык: C++ и PL/SQL.

Наша система исползует Plain Old XML, так уж повелось. И на используемые XML нет схем, по большей части. Что тут говорить, если юнит тесты прививаются здесь только второй год и менеджер до сих пор упрекает за время, потраченное на их написание. Да ладно…

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

Как и многие, я думаю, мы многое делаем неоптимально и не лучшим образом. Главное делаем. Пример с XML не исключение.

Добрый день.

Ниже пойдет речь о том, как использовать SQLite в Qt. Автор постарался как можно подробнее рассматривать программирование баз данных в Qt.

Об этих двух замечательных продуктах можно прочитать следуя приведенным выше ссылкам, а мы будем конкретно рассматривать программирование БД в Qt, в частности, на примере SQLite. Скажу только, что SQLite несколько отличается от «обычных» баз данных, таких как MySQL тем, что «не обладает» клиент-серверной архитектурой. То есть движок БД не является отдельно работающим процессом, с которым взаимодействует программа. SQLite представляет собой библиотеку, с которой компонуется ваша программа и, таким образом, движок становится составной частью программы. То есть представьте вы решили сохранять все данные, с которыми «сталкивается» ваша программа в обычный файл. В один прекрасный день вы решаете сохранять данные в файле, но организовав это с «реляционной» точки зрения. После этого вы поняли, что новая структура файла должна «распознаваться особым образом». С этого, как минимум, следует, что вам нужно предоставить некоторый API, обеспечивающий связь между этим файлом данных с приложением. В общем, следуя логической постановке приведенного сценария у вас рождается система БД, не требующая сервера БД и собственно, клиента. Получается достаточно быстрая по сравнению с «клиент-серверной» БД система, и сама программа упрощается.