Недавно мое внимание привлек факт, что в обновлениях прошивок для Linksys WRT120N используют какую-то обфускацию. Мне показалось, что будет интересно порыться в ней, и я решил взглянуть.

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


Как вы можете видеть, есть небольшой блок данных, сжатых LZMA — это просто HTML-файлы для веб-интерфейса роутера. Большая часть прошивки состоит из каких-то странных, случайных данных. Т.к. мне больше ничего с ней не сделать, а любопытство все сильнее пыталось одолеть меня, я купил эту модель роутера себе (как они стоимость Amazon Prime-то взвинтили!).

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

   Привествую, Хабр!

   Продолжаем цикл статей про программирование видеокамеры в Linux. В первой части [1], мы рассмотрели механизм открытия и считывания первичных параметров видеоустройства. Была написана простенькая утилита catvd. Сегодня расширим функционал нашей маленькой программы

В данном топике хотелось бы поговорить о повышении производительности при работе с таблицами.

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

Как правило, это происходит из-за плохо спроектированной схемы – изначально не рассчитанной на оперирование большими объемами данных.

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

Введение

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

В этой статье будет рассмотрен алгоритм An Enhanced Self-Organizing Incremental Neural Network, являющийся расширением базовой модели SOINN и частично решающий озвученные проблемы.

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

Я отошел от своего выгорания только недавно — несмотря на то, что случилось оно несколько лет назад. Да, мне было непросто… очень непросто. Когда я думаю о произошедшем, на ум приходит немало причин тому, что случилось со мной — но самое интересное заключается в том, что каждой из них я никогда раньше не придавал значения. Хотите повторить мой путь и выгореть? Пожалуйста, у меня готов целый список, как следует поступать в таком случае:

1. Думать о проекте и только о нем

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

Уже было много постов о резервном копировании, особенно много для ОС Linux. Озаботился и я настройкой резервного копирования.
Требовалось создавать бэкапы системы, данных с примонтированного раздела и LVM томов (диски виртуальных машин). Были мысли использовать Bacula, т.к. знаком с ней, но поскольку дома только 1 компьютер клиент-серверная архитектура только создавала бы дополнительные сложности при восстановлении в случае повреждения системы. Значит систему и данные просто копируем, образ LVM раздела создаем с помощью dd. Хотелось делать резервную каждый день (хотя бы данных) и хранить минимум 14 дней. Но поиски готовых и простых решений, удовлетворяющих всем потребностям не увенчались успехом. А значит берем в руки bash и пишем свой велосипед. В этой статье я делюсь тем, что вышло.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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

Для понимания статьи Вам понадобятся минимальные навыки программирования и владение математикой на уровне 9 класса средней школы. Статья рассчитана на людей не знакомых с методами оптимизации или только делающих первые шаги в этом направлении.

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

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

Введение

В алгоритмическом трейдинге при создании механических торговых систем (МТС) очень важен вопрос времени жизни торговых алгоритмов. Да, и найти их в принципе достаточно сложно. В условиях постоянно меняющегося рынка рано или поздно наступает момент, когда даже самый совершенный и прибыльный алгоритм начинает приносить убытки. И его нужно, что называется, «подкручивать» или оптимизировать под текущие условия рынка. Одними из самых распространенных являются торговые системы (ТС), работающие со свечными графиками с их многообразием индикаторов для технического анализа.

Concise Binary Object Representation (сжатое бинарное представление объекта) — формат данных, который был спроектирован таким образом, чтобы обеспечить максимально простой код реализации, формирования компактных выходных данных и возможность расширения формата без необходимости обмена информацией о версии.

Стандарт формата CBOR был официально анонсирован комитетом IETF в октябре 2013 года в новом документе RFC 7049, авторами которого являются Carsten Bormann и Paul Hoffman. Взглянув на имя первого автора, можно предположить другую причину происхождения аббревиатуры для названия формата, но возможно это просто совпадение. Формат CBOR получил MIME-тип application/cbor.

На данный момент существует, вероятно, сотни всевозможных бинарных форматов для представления структурированных данных, ряд которых стандартизирован, популярен и широко применяется (например, BER и DER для ASN.1, MessagePack и BSON). Все существующие стандарты решают поставленные перед ними задачи, и CBOR здесь не исключение. К формату было предъявлено семь важных требований, и, поскольку ни один из существующих форматов в полной мере не мог им удовлетворить, был создан новый (да, тут напрашивается картинка ).

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

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

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

Основные понятия
Изображение — отображение объекта на воспринимающие органы. То есть, описание объекта, как множество признаков. Часто объект представляется в виде вектора. Если множество признаков постоянное, то объект отождествляется с его изображением.
Образ (класс) — подмножество множества объектов или изображений.
Решающая функция — функция, на вход которой подается изображение, определяющая принадлежность объекта некоторому классу.

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

Доброго времени суток!

Этот пост для тех, кто работает над очередным API на языке Java, либо пытается усовершенствовать уже существующий. Здесь будет дан простой совет, как с помощью конструкций ? extends T и ? super T можно значительно повысить удобство вашего интерфейса.

Введение.

Анализируя замечания предыдущего поста (Qt Designer & Runtime Qt библиотеки на службе OpenCV...), пришлось более детально проработать устройство видеозахвата библиотеки OpenCV и методы разделения библиотек runtime и виджетов.
Работа с Qt Designer удобна (я — лентяй), поэтому и возник компонент проектирования интерфейса для CvCapture. После начала работы подтянулось и «научное » тому объяснение — удобно применить нечто похожее, скажем, при проектировании интерфейса свойств или параметров приложения, использующего устройство видеозахвата.
Пока идёт скачивание архива проекта, читайте далее.

Благодарности.

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

Библиотека времени выполнения.

Итак, библиотека OpenCV установлена, примеры кода просмотрены. Самое время «прикрутить» устройство видеозахвата к Qt. Да не просто так, а чтобы и изображения получать, меняя устройства динамически. Да, чтобы помнило все пути к изображению, видео. Да, чтобы и номера камер переключало. Да, чтобы и… пост покороче получился.

Библиотека.

Чего проще! Наследуем новый класс библиотеки от QObject, прячем ненужные разработчику поля и методы в приватный класс как элемент коллекции QScopedPointer, монтируем сигналы оповещения и слоты-обработчики.

Дано: полное отсутствие интернета и виднеющийся WiFi hot-spot, в котором предлагают ввести логин-пароль. Или 3G, в котором нет интернета (потому что закончились деньги), но есть страничка провайдера с предложением дать оных денег.
Задача: получить интернет (легальным?) методом посредством туннелирования его через DNS.
Решение: linux+ iodine + routing + NAT + squid, и всё это под управлением network manager'а.
В статье: описание организации DNS туннеля посредсредством программы iodine, нюансы организации маршрутизации через образовавшийся туннель, самописный помощник для iodine и network manager.

Лирика: Занесла меня судьба на славный остров Кипр, кой славен своим П/пафосом, фраппэ и таким интернетом, после которого российские опсосы начинают выглядеть ангелами во плоти. В частности, попытка подключиться к интернетам закончилась ожиданием, что местный провайдер (Сyta) смилостивится, таки закончит пить оный фраппэ и дотянет до меня поганый ADSL 4Мб/768кбит всего-навсего за €151 (подключение) + €40 в месяц (за 4 мегабита! >_<). Ожидание тянулось и тянулось (как бы уже третья неделя пошла), а рядом был славный PrimeTel, который предлагал за €4/час (172р/час) осчастливить меня интернетом прямо тут и сейчас через едва видный WiFi. Я бы даже и согласился, но видна точка доступа была только на балконе, а в квартире связь была нестабильной и часто терялась. Так что оставалось одно решение (помимо взлома WEP-сети соседей, что уж совсем уголовщина) — это злоупотребить сервисом DNS, который безвозмездно, то есть даром, предоставляет PrimeTel для своих незарегистрировавшихся подлюченцев.

Те, кому интересно «howto» — решение далее по тексту, а пока что начнём с теории процесса.

В проекте, над которым я работаю, мы используем огромное количество сторонних библиотек. Многие из них — адаптеры для различных сервисов. Что их объединяет, это то, что они работают с сетью. Json поверх http, soap поверх http, какие-то свои протоколы поверх http. Т.е. все так или иначе используют http. И как ни удивительно, мало кто из них пользуется преимуществами его последней версии. Я не поленился заглянуть в википедию, прошло ровно 14 лет как была принята спецификация http 1.1. И потому я решил обратиться с призывом:


Да, речь пойдет о keep alive. Суть в том, что, начиная с http 1.1, клиент и сервер могут договориться не закрывать установленное tcp-соединение после завершения запроса, а переиспользовать его для следующих запросов. Это нужно потому, что на установку соединения требуется время. Иногда это время больше, чем время самого запроса. И если все серверы уже давным-давно такую возможность поддерживают, а все браузеры и большинство других клиентов её используют, то у разработчиков различных библиотек для популярных языков программирования здесь почему-то пробел.

Если и есть что-то, что веб-разработчики любят, так это знать что-то, что лучше традиционного. Но традиционное является таковым по одной причине: это дерьмо работает. Что-то давно беспокоило меня во всей этой шумихе вокруг Node.js, но у меня не было времени разобраться, что именно, пока я не прочитал полный боли в жопе пост от Райана Дала, создателя Node.js. Я бы забыл его, как любое очередное нытьё какого-то осла о том, что Unix слишком сложен. Но, как полицейскому, который, жопой чуя, что что-то не так с этой семьёй в микроавтобусе, останавливает его и находит пятьдесят килограммов героина, мне показалось, что что-то не так с этой слезливой историей, и возможно, просто возможно, он понятия не имеет, что делает, и много лет программирует, никем не контролируемый.

Проведено сравнение производительности ядер HTTP-серверов, построенных с использованием семи C/C++ библиотек, а также (в познавательных целях) — других готовых решений в этой области (nginx и node.js).

HTTP-сервер — это сложный и интересный механизм. Есть мнение, что плох программист, не написавший свой компилятор, я бы заменил «компилятор» на «HTTP-сервер»: это и парсер, и работа с сетью, и асинхронность с многопоточностью и много чего еще....

Тесты по всем возможным параметрам (отдача статики, динамики, всевозможные модули шифрования, прокси и т.п.) — задача не одного месяца кропотливой работы, поэтому задача упрощена: будем сравнивать производительность ядер. Ядро HTTP-сервера (как и любого сетевого приложения) — это диспетчер событий сокетов и некий первичный механизм их обработки (реализованный в виде пула потоков, процессов и т.п.). Сюда же можно отнести парсер HTTP-пакетов и генератор ответов. На первый взгляд, все должно свестись к тестированию возможностей того или иного системного механизма обработки асинхронных событий (select, epoll и т.п.), их мета-обёрток (libev, boost.asio и др.) и ядра ОС, однако конкретная реализация в виде готового решения дает существенную разницу в производительности.

Был реализован свой вариант HTTP-сервера на libev. Конечно, реализована поддержка небольшого подмножества требований пресловутого rfc2616 (вряд ли ее полностью реализует хоть один HTTP-сервер), лишь необходимый минимум для соответствия требованиям, предъявляемым к участникам данного тестирования,

В одном из проектов компании Itseez, связанных с компьютерным зрением, мы используем Raspberry Pi для обработки видео потока с веб-камеры, и недавно столкнулись с проблемой записи видео на флеш-карту. Трудность состояла в том, что ресурсы ЦП съедались другими более важными задачами, однако сохранять видео все же было нужно. Причем предпочтений, каким кодеком сжимать и какой формат использовать, не было, лишь бы это никак не сказывалось на fps (количестве кадров в секунду). Перепробовав большое число программных кодеков от RAW до H.264 (использовалась обертка OpenCV над FFmpeg), пришли к выводу, что ничего из этого не выйдет, т.к. при высокой нагрузке fps проседал с 20 до 5 кадров в секунду, при том что картинка – черно-белая с разрешением 320x240. Немного погуглив, выяснили, что в процессоре Raspberry Pi есть аппаратный кодер с поддержкой стандарта H.264 (насколько мне известно, лицензия приобретена только для него). Плюсом ко всему было то, что взаимодействие с кодером реализовано по стандарту OpenMAX, поэтому было решено взяться за написание кода с использованием OpenMAX, и посмотреть, что из этого получится. Получилось, кстати, очень даже недурно!