Погода и государство

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

Цели*

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

Я не вижу реальных целей. Сколково, Сочи, ВТО. Мы сделаем, как у них и всё у нас образуется само собой.

Такое ощущение, что люди высшее образование не получали. Я честно не понимаю причин, почему так трудно анализировать текущую обстановку и выносить адекватные решения. Нужно-то всего лишь верно расставить приоритеты. Бизнес зарабатывает деньги и платит налоги - очевидна выгода для государства. Зарабатывание денег у нас в обществе будет происходить постоянно. Государство у нас богатое, финансов крутится уйма. Но качество продукта на выходе хромает. Нельзя зарабатывание денег и их объёмы ставить выше качества производимого товара - это вам расскажет любой здравомыслящий глава компании.

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

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

Node.Js: модули на C/C++

Во время работы встала задача научиться писать интерфейсы к C/C++ функциям для Node.JS. Эта задача становится всё более актуальной в свете того, что основные камни летят в node именно из-за нехватки некоторого привычного для разработчиков функционала (ничего они не понимают в жизни).
В данной статье я хотел бы немного описать своё видение платформы Node.JS, а также поговорить немного о том, как писать модули к Node на C++ .
Сразу оговорюсь: я не профессиональный web-разработчик, никогда  в жизни профессионально не занимался даже бразуерным JavaScript-ом до недавнего времени, когда ко мне обратились примерно со следующей просьбой: "Узнай, что  вообще такое этот node и попробуй прикрутить туда какую-нибудь интересную штуку, например мои любимые linux-библиотеки на C". Было бы знание, да незнание помогло. Порой труднее оказывается объяснить, что такое серверный JavaScript людям, для которых DOM - родной дом.
На первый взгляд node действительно оказывается привлекательным для работы с сокетами, портами и вообще всем, что нужно время от времени опрашивать и периодически формировать на это какие-либо ответы. Его однопоточной модели с Event Loop оказывается вполне достаточно для проектирования приложений в рамках своих "родных" модулей, то есть философия данной платформы является вполне оправданной и самодостаточной. Один из самых полных обзоров node на языке Пушкина http://fprog.ru/2010/issue6/dmitry-demeshchuk-node.js-vs-erlang/ изложен именно в ключе сравнения с языком Erlang, который на сегодня является одной из самых эффективных платформ для создания коммуникационных узлов в сети.
"Ну а как же тонны уже написанного кода, а также инструменты, без которых нельзя?"
Этим, собственно, сейчас и приходит ся заниматься сообществу node.js-разработчиков.

Первую статью хотелось бы посвятить обзору важных составляющих движка V8, на котором, собственно, и написан node.js и благодаря которому в Chrome и в Node так быстро обрабатывается JavaScript.

Первое и самое важное, что нам необходимо для нашей задачи - заголовочный файл v8.h или его Doxygen представление (например http://bespin.cz/~ondras/html/).

Основной элемент представления в V8 -  Handle, который представляет нам любую структурную единицу языка JavaScript, а также взаимодействует со сборщиком мусора V8.
Все эти элементы существуют в определённом scope, который мы явно определяем.
Через определённые промежутки времени сборщик мусора V8 занимается удалением из памяти handle-ов, на которые больше никто не ссылается, таким образом освобождая место в куче для новых объектов JavaScript.

Правда тут есть одно исключение - помимо обычных handle-ов (локальных, Local) существуют также и постоянные, которые находятся вне ведения сборщика мусора (Persistent).
Каждый Handle может содержать в себе некоторый JavaScript-объект.
Структура объектов JavaScript в представлении V8 имеет следующий вид:

Значения, которые мы передаём в наш модуль из JavaScript - как правило, Value и должны быть явно преобразованы к тому типу, который мы ожидаем с помощью встроенных в V8 преобразователей типов.

Раз мы пишем модуль, значит нам нужно представить в нём определённый набор функций, которые будут выполнять C/C++ код, но при этом могут быть вызваны из JavaScript (что-то вроде FFI).

Начнём с очень простого. Модуль, написанный нами на C++ и запрашиваемый в Node (require('./our_module')) есть не что иное, как обычный JavaScript-объект. Задача, которая стоит перед нами - проста: описать необходимые поля этого модуля. В случае, когда мы имеем библиотеку функций на C удобно представить поля нашего объекта, как набор функций - просто чтобы не мучаться с архитектурой и не городить новые сущности.

#include <stdio.h>
#include <node.h>

using namespace v8;

static Handle<Value> ExampleFunction(const Arguments &args)
{
    printf("DEBUG:: This is our example function\n");
}

extern "C" void
init (Handle<Object> target)
{
HandleScope scope;
    target->Set(String::NewSymbol("ExampleFunction"), FunctionTemplate::New(ExampleFunction)->GetFunction());
}

В V8 для того, чтобы получать в Run-time какие-либо новые JavaScript функции, должен быть использован объект v8::FunctionTemplate. Он является связующим звеном между реальной функцией и контекстом выполнения. Наш основной объект, который мы запрашиваем, носит название target. В функции init мы просто задаём поле с именем ExampleFunction нашего основного объекта как функцию, взятую из v8::FunctionTemplate. Единственный аргумент функции, на которую ссылается FunctionTemplate имеет тип v8::Arguments - это массив из элементов v8::Handle аргументов функции, которую мы вызвали из JavaScript. Наша функция также будет возвращать Value (помним, что в JavaScript динамическая типизация).
Для того, чтобы собрать наш модуль, редактируем файл wscript:

srcdir = ''
blddir = 'lib'
VERSION = '0.0.1'

def set_options(opt):
  opt.tool_options('compiler_cxx')

def configure(conf):
  conf.check_tool('compiler_cxx')
  conf.check_tool('node_addon')
  conf.env.append_unique('CXXFLAGS', ["-lpthread"])

def build(bld):
  obj = bld.new_task_gen('cxx', 'shlib', 'node_addon')
  obj.target = 'sample'
  obj.source = './binding.cc'

Собираем и тестируем:

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

Ссылки:
http://code.google.com/apis/v8/embed.html
http://howtonode.org/how-to-module
http://fprog.ru/2010/issue6/dmitry-demeshchuk-node.js-vs-erlang/

RTLS: методы определения координат

Сегодня попытаюсь определиться, каким способом в рамках небольшого помещения можно определять координаты тела. Пресловутое тело это мы снабжаем меткой, которая способна отправлять на некоторое расстояние набор дискретных сигналов. Буквально сразу можем оговориться, что скорее всего речь здесь пойдёт об активной радиочастотной метке (Active RFID tag). Определим считыватель, как устройство, воспринимающее сигналы от метки.

Подход I

"Радарный способ", по углу отклонения (angle of arrival).

Решение подсказывают нам военные. Антенна нашего считывателя должна уметь определять, в какой стороне от неё находится метка. Этого можно достичь двумя способами - натыкать на считыватель много-много узконаправленных антенн по кругу и смотреть, на какую из них пришёл сигнал, или же просто вращать одну антенну (как поступают военные) и ждать прихода сигнала, получая таким образом угол a. Также для точного позиционирование нам необходимо определять расстояние от считывателя до метки (b), либо использовать 2 считывателя и по известным двум углам и расстоянию между считывателями рассчитывать положение метки.

Достоинства:

+ простота алгоритма позиционирования

+ при использовании большого количества антенн - высокая скорость.

Недостатки:

- большие затраты на аппаратную часть

- низкая точность позиционирования.

Подход 2

"Недоэхолот", по времени прихода сигнала (Time of Arrival)

Зная время, за которое сигнал от метки доходит до считывателя, можем определить расстояние между ними. Соответственно, если считывателей 3, можно точно рассчитать координаты метки на плоскости, если 4 - в пространстве.

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

Достоинства:

+ Простота алгоритма позиционирования.

Недостатки:

- Сложная аппаратная часть - наличие часов в метке и в считывателе

- Необходимость наличия как минимум 3-х считывателей.

Подход 3

"Мне хватило сил тебя услышать" Определение расстояния по мощности сигнала (Recieved Signal Strength Indication)

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

Здесь также может быть 2 подхода:

/Измерение мощности аналогового сигнала от метки

/Последовательное уменьшение дальности действия считывателей

Достоинства:

+ Простота алгоритма позиционирования

+ Отсутствие необходимости синхронизации по времени.

Недостатки:

- Значительные аппаратные затраты

- Низкая точность ввиду неоднородности мощности сигнала метки во всех направлениях

- Плохая помехозащищённость.

Подход 4

"Кто что слышал?" Разница во времени прихода сигнала (Time Defference of Arrival)

Подход схож с предыдущим. Каждый считыватель считает время прихода сигнала от метки к нему, а затем вычислительная среда считает разницу между этими временами. Немного раскинув своими железными мозгами, та самая среда выдаёт нам координаты метки, как пересечение трёх гипербол (4-х гиперболоидов в 3D).

Достоинства:

+ Простые аппаратные ресурсы - не нужны часы в метке.

Недостатки:

- Низкая, по сравнению с предыдущим подходом, точность

- Сложность алгоритма позиционирования

- Необходимость наличия 3-х считывателей.

в статье использованы материалы исследовательской работы компании Nanotron Technologies.

Мне по роду прошлой деятельности пришлось реализовать 3-й подход (RSSI) - система работала с точностью 1,5 м, однако была очень требовательна. Оборудование было уже готовое - отечественный считыватель, активно применяемый в автомобильных пропускных системах и активные метки. Система работала на ура, если не поворачивать метки вокруг вертикальной оси - тут начинались чудеса. Это происходило как раз вследствии неоднородности диаграммы направленности метки.

Сейчас же, взяв за основу подход №2, можно попытаться построить систему не такую требовательную к аппаратным ресурсам, однако более надёжную. Об этом в следующем посте.

Системы позиционирования реального времени (RTLS)

Существует задача определения местоположения объектов в пространстве. У нас в стране к этому вопросу подошли как всегда основательно: стали палить из пушки по воробьям, создавая, а точнее, развивая созданную ещё в бородатые 1982-е годы систему ГЛОНАСС. А стоит ли заниматься вопросами позиционирования более мелких масштабов - масштабов предприятия/больницы/поля боя? Здесь, как говорится, непаханное поле - готовые решения являются достаточно дорогими и представлены в основном зарубежными поставщиками, а нас такие вещи не устраивают. Различных разрозненных документов, посвящённых данной тематике, можно найти массу; в продаже даже недавно появилась книга из серии "для чайников". Занимаясь бакалаврской работой, немного кореллирующей с данной тематикой - RFID, пришёл к выводу, что в последнее время вопросом построения RTLS на западе озадачились достаточно сильно. Проблема кажется не такой сложной, ведь мы же занимаемся нанотехнологиями - что нам до такой ерунды, однако и здесь есть масса вопросов, над которыми можно хорошенько потрепать свой ум.

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

В следующем сообщении будет обзор современных методов локации, их достоинства и недостатки.

Собака в метро

Давным-давно случилась со мной такая история... Ехали мы на работу, как вдруг увидели ЭТО =) Фотоаппарат у меня оказался очень в тему. Правда потом пришлось убегать от сотрудников метрополитена, которые хотели получить свою долю кассовых сборов в размере 500 р, но это уже мелочи отечественного кинематографа =) На самом деле, предложили уже включить это в фильм про разумных собак в нашей жизни, так что этот пёсик может скоро станет звездой!

Fluxbox

Забил я на все "за" и "против" KDE и GNOME и поставил fluxbox. Был приятно удивлён. Подобной простоты и гибкости в меню, в горячих клавишах, я ещё пока нигде не встречал.Итак: состав меню мы правим в .fluxbox/menu. Если используем vim, то смело качаем из любимых портеджей fluxbox-syntax. Теперь нам легко и приятно править наше меню.
Аналогично по простоте, но с другим синтаксисом работаем с файлом keys оттуда же. Немного повизимся с init (я убрал стрелочки из нижней панели) и вуаля, всё супер =) Спасибо Gentoo за мануалы и за emerge!

(на картине)
- MOC Player - консольный музыкальный плеер
- IrrSi - консольный IRC-клиент
- Mplayer (думаю, знаете)

Даёшь простоту и минимализм ;)

PS: Исправил одну вещь: чтобы в заголовках окон и в меню работал русский язык, fluxbox (в gentoo) должен быть собран с USE-флагом truetype и в .fluxbox/overlay везде должен быть прописан шрифт, поддерживающий русские буквы (у меня например спокойно работают terminus из пакета terminus-font и простой советский arial).

Hello, world!

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