Привет, хабр. По работе мне приходится иметь дело с OBIEE (Oracle Business Intelligence Enterprise Edition) в качестве разработчика и администратора, поэтому я решил поделиться тем объемом знаний, который успел накопить. Надеюсь, кому-нибудь это поможет в освоении системы. Сначала я планирую рассказать про систему в целом, затем — про архитектуру и взаимодействие компонентов, а в конце — рассказать про те особенности, с которыми пришлось столкнуться за время работы.

Обзор системы

Oracle Business Intelligence Enterprise Edition (OBIEE, OBI) — программная платформа для решения задач бизнес-аналитики: интерактивных и публикуемых отчетов, мониторинга KPI и бизнес-процессов. Является потомком Siebel Analytics. Основные функциональные части, доступные пользователям:

• Answers (также называются Interactive Dashboards) — построение интерактивных отчетов, доступных для пользователей через веб-интерфейс OBIEE. Единицей отчетности является analysis — простой отчет, как правило, включающий в себя одно отображение (таблицу, график, диаграмму и т.п.). Analysis объединяются в информационные панели (Dashboards), с которыми работают конечные пользователи. Информационные панели также могут включать в себя приглашения (prompts) — элементы настройки, с помощью которых пользователь может взаимодействовать с панелью.
• Publisher (также иногда в него включают Delivers) — средство создания и рассылки статических отчетов. Т.к. publisher развился из отдельного продукта, то в нем есть возможность строить отчеты на собственной модели данных, независимой от модели данных OBI, однако можно использовать и общую модель. Также есть возможность рассылки существующих отчетов из answers.
• Action Framework — набор средств для выполнения каких-либо автоматизированных действий из OBIEE — например, рассылка отчетов по достижению показателем определенного значения, вызова внешних веб-служб, вызова java кода и т.п. Действия могут быть объединены в цепочки. Возможно настройка различных каналов оповещения пользователей — e-e-mail, sms, пейджер и т.п.
• Scorecard and Strategy Management — средства для отслеживания ключевых параметров производительности (KPI) и работы с системами показателей (Scorecard — http://en.wikipedia.org/wiki/Balanced_scorecard). Используются для наглядного отображения статуса выполнения целей (компании, проекта). Доступ пользователей, как и в случае с answers, осуществляется через веб-интерфейс.
• Marketing — средства интеграции с Siebel Marketing.
• Office Tools — средства интеграции с Microsoft Office.

Архитектура

OBIEE, по сути, является посредником между источниками данных и пользователями (пользовательскими отчетами). Система не хранит у себя данных (за исключением кэшей) — все отчеты строятся «на лету», путем выполнения запросов к источникам данных (картинки из книги OBI 11g Developer’s Guide):

OBIEE поддерживает множество различных источников данных, среди которых реляционные базы, системы OLAP, файлы и apache hadoop. Система позволяет объединять в одном отчете данные из различных источников, объединяя их между собой по заданным правилам.
В центре системы находится единая модель данных (также называемая репозиторием) — описание логической модели бизнес-области и привязку ее к физическим источникам данных. Модель состоит из трех слоев — презентационного, бизнес и физического. В бизнес-слое описывается логическая модель (которая понятна конечным пользователям), в форме многомерной модели — фактов и измерений, а также описывается привязка логических атрибутов к физическим источникам. Презентационный позволяет разбить логическую модель на несколько предметных областей и ограничить доступ пользователей к различным показателям и атрибутам. Физический слой содержит описание источников данных — таблиц, полей, ключей, кубов данных. Создание модели данных (репозитория) выполняет разработчик с помощью специальной программы — Oracle BI Administration Tool.
Когда пользователь открывает отчет, сервер презентаций (Presentation Server) генерирует запрос на языке Logical SQL к серверу BI. Сервер BI разбирает запрос, и переводит его в запросы к источникам данных на их «родных» языках — sql, mdx и т.п. После получения данных от источников сервер объединяет их, проводит различные действия над данными (например, вычисляет агрегаты, если это необходимо), и возвращает результат серверу презентаций. Сервер презентаций, в свою очередь, отрисовывает полученные данные в веб-интерфейсе или генерирует статичный отчет.

Серверная часть OBIEE включает в себя несколько разрозненных компонентов, часть из которых управляется сервером приложений Weblogic, а другая часть существует как обычные (нативные) программы и управляется компонентом oracle process manager (opmn). Также OBIEE использует для хранения части служебных данных реляционную базу (Oracle, MS SQL, IBM DB2 или MySQL). Управление доменом OBIEE осуществляется с помощью веб-интерфейсов Weblogic Administration Console и Fusion Middleware Enterprise Management Console.

Как происходит работа с системой

Допустим, существует потребность бизнес-пользователей получать аналитическую информацию о состоянии какой-либо области деятельности компании (например, об объемах продаж в ритейлинговой сети магазинов). Как удовлетворить потребности пользователей с использованием OBIEE? Шаги будут примерно следующими (в данном случае речь об интерактивных отчетах Answers):

1. Определение доступных данных для построения отчетности
   У бизнеса может быть уже подготовленное и работающее хранилище данных для получения непротиворечивых и консолидированных данных. Тогда задача упрощается — мы берем данные из существующей витрины и напрямую обращаемся к ним из OBIEE. Другое дело — если ХД отсутствует, и имеются, например, данные из нескольких разрозненных систем. Как правило, такие данные находятся в нормализованном виде (3 НФ или выше), и очень детальны, что не есть хорошо для построения отчетности. В этом случае необходимо проектирование и построение витрины данных со схемой вида «звезда» или «снежинка» (или нескольких, в зависимости от сложности данных). Витрина может быть реализована в виде таблиц или, например, представлений (обычных или материализованных). Естественно, для этого нужна постоянно работающая СУБД, способная выдерживать достаточно большое количество запросов.
   Также возможен вариант, когда данные доступны в виде OLAP — тогда, как правило, никакой доработки не требуется, т.к. это означает, что многомерная модель данных уже построена и функционирует.
2. Построение модели данных
   Существующие данные необходимо описать и связать логические атрибуты (например, метрики объемов продаж) с физическими атрибутами в СУБД или сервере OLAP. На основе этих данных строится многомерная модель — описание данных в терминах фактов, измерений, атрибутов измерений и иерархий.
3. Создание репозитория
   Теперь разработанную модель данных нужно перенести в репозиторий OBIEE. Это делается в Oracle BI Administration Tool (упоминавшейся чуть выше). Разработка проходит в три этапа — импорт метаданных источников, построение бизнес-слоя и построение презентационного слоя. Как правило, имеется только один источник данных, но могут быть и более сложные сценарии, например, с объединением данных из реляционной СУБД и OLAP, или объединение данных с разными уровнями гранулярности из нескольких СУБД. В этих случаях разработчик также должен правильно настроить «взаимоотношения» между источниками. Построение бизнес-слоя в основном состоит из переноса атрибутов физического слоя, описания иерархий, выбора типов агрегаций метрик и настройку источников для логических таблиц. Презентационный уровень, как правило, является отображением «1 в 1» бизнес-слоя, иногда разбитого на отдельные области (если, например, хочется разделить доступ пользователей к данным). Также стоит отметить, что OBIEE имеет некоторые средства для совместной разработки репозиториев — есть возможность их слияния из разных версий, а также репозиторий можно хранить в виде набора xml файлов, для удобства работы с системами контроля версий.
4. Разработка отчетов
   После формирования репозитория и загрузки его на сервер начинается основная фаза — разработка отчетов. Сначала разрабатываются отдельные анализы, затем они интегрируются в информационные панели. Как правило, каждый разработчик работает над своим набором анализов и дашбордов, т.к. средств для совместной разработки нет (все происходит в веб-интерфейсе), и при одновременной правке один будет затирать работу другого:)

Немного из личного опыта

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

• OBIEE не всегда правильно работает со схемами типа «снежинка» в модели данных. Это значит, что не всегда генерируется правильный SQL запрос из отчета. По возможности нужно переводить такую схему в «звезду» на уровне бизнес-слоя. К примеру, если есть таблица «Клиент», которая ссылается на таблицу «Класс клиента» (физическое лицо, корпоративный клиент и т.п.), то в бизнес-слое их нужно свести в одну логическую таблицу «Клиент» с полным набором атрибутов. Ситуация усложняется, когда есть связи таблиц фактов через несколько таблиц измерений. В таких случаях нужно следить за правильностью генерации запросов.
• В OBIEE есть возможность составления анализов на основе прямых запросов к БД. Для этого требуется изменение конфигурационного файла NQSconfig.INI. Эта возможность часто упрощает жизнь, если нужно реализовать хитрую логику отображения, не усложняя без необходимости модель данных. Однако в этом случае надо помнить, к каким данным должны иметь доступ бизнес-пользователи, и не давать возможность выполнения запросов к базе всем подряд.
• Необходимо правильно настраивать кеширование данных таблиц. В том случае, если в данных планируются изменения в течение рабочего дня, которые пользователи должны видеть в отчетах — необходимо либо отключать кеширование, либо вручную (через WLST) обновлять кеш. Также хорошей практикой является «разогрев» (seeding) кеша перед началом рабочего дня пользователей, чтобы пользователи могли сразу полноценно пользоваться отчетами.
• Следует помнить, что функционал информационных панелей как веб-приложения сильно ограничен. Если требуется серьезная интерактивность взаимодействия пользователей с интерфейсом, то лучше смотреть в сторону других BI средств, например, стека MS. Все, что можно получить в OBIEE — это выбор фильтров, работа с данными в таблицах (сортировка, порядок столбцов, создание групп, добавление итогов и т.п.) и так называемые «master-detail» события — когда пользователь может нажать на ячейку в одной таблице, а в соседнем графике или таблице данные автоматически отфильтруются по выбранному значению в ячейке. Есть функционал действий (actions), но он тоже сильно ограничен — есть только переход по URL, вызов REST метода и переход к другой информационной панели.

Мобильная бизнес-аналитика

В арсенале OBIEE также есть средства для мобильной аналитики (с использованием мобильных устройств):

1. Oracle BI Mobile — приложение для ios, которое позволяет просматривать контент информационных панелей и анализов на мобильном устройстве. Отображение производится почти без изменения внешнего вида отчетов, отчего все выглядит немного в стиле 90-x:)
2. Oracle BI Moblie App Designer — приложение, интегрируемое в OBIEE, позволяет создавать отчеты на HTML5 с использованием модели данных из OBIEE или Publisher. Фактически, это генератор веб-приложений — каждый отчет состоит из нескольких страниц, с интерактивностью и переходами между ними. Плюсом такого решения является то, что приложения будут выглядеть одинаково в полноценном браузере и на устройстве, а также отсутствие необходимости установки отдельного приложения. Минус — то, что данные не кешируются на устройстве, соответственно, пользоваться им можно только при наличии интернет-соединения. Mobile App Designer был выпущен совсем недавно, и еще не включен в основную поставку OBIEE.

Литератуа

1. Официальная документация от Oracle
2. Oracle Business Intelligence 11g Developers Guide — Mark Rittman
3. Oracle Business Intelligence Enterprise Edition 11g: A Hands-On Tutorial
4. Oracle Business Intelligence: The Condensed Guide to Analysis and Reporting
5. http://www.oraclebi.ru/

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

Итак, вы ищете работу.
Первое, что вам нужно понять, и даже не понять, а проникнуться этим (причем, желательно в смысле хайнлайновского «грокнуть»*): вы продаёте товар на высококонкуретном рынке. Вот чем, на самом деле, вы занимаетесь. Товар — это вы, вместе с вашими знаниями, опытом, привычками, характером, внешностью, речью и всем остальным. Играет роль всё. Разные составляющие кандидата имеют разные приоритеты, но при равных наиболее приоритетных составляющих будет играть роль каждая мелочь. Запомните: вы продавец, работодатели — покупатели. Мы все скромные люди, нас никто, к сожалению, не учил торговать (а частенько даже внушали, что торговля — это чуть ли не удел низшей касты), поэтому тут придется преодолеть некоторую ломку стереотипов и шаблонов.
Если вы это «грокнули», то всё дальнейшее следует абсолютно логически.

1. Резюме.
Составьте настолько полное резюме, насколько это возможно. Охватите свой стаж за последние 10 лет (а лучше — прямо от ВУЗа, даже если после выпуска прошло уже 20 лет). Ваше резюме — это упаковка вашего товара. Но не надо писать «Войну и мир». Нужна конкретика. На каждой позиции должны быть указаны 2 раздела: Обязанности и Достижения. Запишите в Обязанности всё, чем вы занимались. В Достижения запишите всё, чего вы достигли. Не бывает работы без достижений. Не пишите слов «принимал участие в», пишите «делал то-то и то-то в рамках того-то». Не скромничайте. Но и не пишите того, о чем не сможете рассказать. Если дружите с английским — обязательно сделайте и англоязычный вариант резюме.

2. Cover letter.
Некоторым работодателям требуется письмо, вкратце описывающее вас. Сделайте его на основе резюме. Письмо должно умещаться на А4, так что включите туда только самые основные моменты.

3. Социальные сети и сайты.
Это реклама вашего товара. Сделайте так, чтобы о вашем поиске работы узнало как можно больше народу. Создайте свой сайт и выложите туда резюме, создайте аккаунты на LinkedIn и в HeadHunter (опять же на основе своего резюме), расскажите всем френдам в Твиттере, Фейсбуке, ВКонтактике, Одноклассниках, ЖЖ, etc. о том, что вы ищете работу, дайте ссылки на свои страницы с резюме. Стоит ли использовать сайты поиска работы в РФ, отличные от HH.RU? Дело ваше, но, по моему опыту, проку от них никакого. Все серьезные и хорошие работодатели пользуются HH.RU либо серьезными кадровыми агентствами, которые тоже регулярно ходят на HH.RU.

4. HeadHunter.
Вы выставляете свой товар на прилавок на Главном Колхозном Рынке Страны. Я думаю, большинство из нас может и хочет работать не на какой-то одной конкретной позиции, всегда есть некоторый список предпочтений. У кого-то он больше, у кого-то он меньше, но есть он практически у всех. Под каждую желаемую позицию отредактируйте свое резюме (особенно это важно тем, у кого нелинейный опыт работы, то есть тем, у кого стаж выглядит, например, так: разработчик — сисадмин — тестировщик — пиэм), выделив и усилив места, характерные для желаемой позиции, и ослабив или даже вовсе убрав все лишнее. Сделайте автопоиски по каждой желаемой позиции и просматривайте регулярно всё новое, что появляется. Откликайтесь на всё подходящее. Регулярно обновляйте свои резюме (вручную 2-3 раза в день), чтобы они постоянно были на виду.

5. Вас приглашают на собеседование.
Покупатель подошёл к прилавку. Улыбаемся и машем. Обычно это звонок от HR, но может быть и e-mail. Разговаривайте спокойно и доброжелательно. Согласуйте время и место встречи. Попросите прислать схему, дату и время вам на e-mail. Обычно, кстати, HR-ы это сами предлагают, это обычная практика. Обязательно ответьте на присланное письмо подтверждением встречи. Даже если об этом не просили — это будет оценено. Занесите встречу в календарь на телефоне. Кстати, если на этом этапе со стороны HR имеет место быть некая расхлябанность или неточность, то это тревожный звоночек.

6. Собеседование.
Покупатель вертит товар в руках и думает, купить или не купить. Приценивается, принюхивается, пробует на зуб. Я вам рекомендую идти на собеседование в спокойной одежде. Костюм с галстуком и туфлями бывает нужен крайне редко, и обычно об этом сообщают специально во время согласования встречи. Но в вас не должно быть ничего, что может спугнуть покупателя. Вы должны показать, что ваш товар не взрывоопасен и не токсичен. Это банально, но от вас не должно ничем сильно пахнуть и тем более вонять (носками, потом, перегаром, etc.). Вы не должны блестеть до рези в глазах и сиять красками. Обувь должна быть чистая (мужчинам рекомендую вспомнить «Москва слезам не верит», сцену в электричке). Выходите из дома с получасовым запасом. Лучше посидеть 15 минут в лобби и передохнуть, чем бежать от метро, сломя голову. На собеседовании держитесь с достоинством. О себе рассказывайте спокойно и уверенно. Тщательно присматривайтесь к обстановке, к людям. Возможно, вам что-то не понравится уже сейчас. Задавайте вопросы, не стесняйтесь, но любой свой вопрос обдумывайте. Запомните: товара у вас одна штука, и покупателя выбираете вы сами. Вовсе необязательно продавать вашу прелесть первому желающему. Как говорил персонаж одного мультфильма: «Дураков, поди, много, а зайцев, поди, мало». Собеседование редко где проходит в один этап. Будьте готовы к 2-3-4 этапам. Особенно это касается, если на вас вышли те, кто сдает рабочую силу внаём другим организациям, которые не хотят набирать себе специалистов в штат: конторы типа Епама или Люксофта.

7. В готовности к облому — наша сила.
Будьте готовы к тому, что вам откажут на первом собеседовании. И на втором. И на третьем, и на четвертом. И на последней из 3 ступеней 5-го собеседования. Причины вам почти никогда никто не назовёт. Кстати, а вот спрашивать о них никто вам не запрещает. Звоните и интересуйтесь, вы имеете на это полное право: вы же тратили своё время, в конце-концов, а оно денег стоит. И ваших нервов. Не расстраивайтесь. Делайте выводы, меняйте тактику поведения. В 2013 году период поиска работы (без помощи родственников и знакомых) составлял в районе 5 месяцев. Но многие находили и быстрее. И запомните: лето — мёртвый сезон. В период со второй декады июня и по середину августа прекращается практически вся активность по набору персонала.

8. Держите себя в руках.
Вы встретите очень разных людей. Встречаются хамы. Я не рекомендую хамить в ответ, отвечайте спокойно. Но после собеседования ответьте себе сами на вопрос, хотите ли вы работать в этой компании. Встречаются психологи. В одной компании (системный интегратор средней руки) мне предложили первым делом заполнить анкеты с вопросами типа «как давно вы перестали пить коньяк по утрам?». При этом девушка-HR-психолог позволила себе опоздать на полчаса. Беседа у нас, понятное дело, не состоялась.

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

10. Не отказывайтесь от шансов.
Даже если у вас на руках есть предложение, не отказывайтесь от новых собеседований. Пока вы не подписали договор — вы никому ничего не должны.

Надеюсь, мои наблюдения и советы помогут вам. Желаю вам в новом году найти отличную работу!

___________________________________
* грок, грокнуть (марс., фант., хайнл.) — понимать настолько полно, что наблюдатель становится частью наблюдаемого (С) Р. Хайнлайн, «Чужак в чужой стране».

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

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

При сборке из исходников модули выбираются командой menuselect-newt:

Но в остальных случаях оптимальный вариант — прописать в конфигурационный файл modules.conf список тех модулей, которые не нужны, через директиву noload.

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

Ниже предлагаю свой вариант набора таких директив, который следует добавить к файлу modules.conf и конфигурировать по своему усмотрению.

;  Resources -- ;noload => res_adsi.so                    ; ADSI Resource ;noload => res_config_odbc.so             ; ODBC Configuration   ;noload => res_indications.so             ; Indications Configuration ;noload => res_odbc.so                    ; ODBC Resource ;noload => res_curl.so                    ; cURL Resource Module ;noload => res_config_curl.so             ; Realtime Curl configuration     ;  PBX -- ;noload => pbx_dundi.so                   ; Do a DUNDi lookup of a phone number. - Requires res_crypto.so noload => pbx_ael.so                      ; For loading extensions.ael  ;  Functions -- ;noload => func_enum.s                    ; ENUMLOOKUP and TXTCIDNAME functions - Requres ? ;noload => func_uri.so                    ; URI encode/decode functions - Requires ? ;noload => func_iconv.so                  ; Charset conversions ;noload => func_srv.so                    ; SRV related dialplan functions ;noload => func_curl.so                   ; Load external URL  ;  Database Call Detail Records -- ;noload => cdr_odbc.so                   ; ODBC CDR Backend - Requires N/A noload => cdr_custom.so                  ; Customizable Comma Separated Values CDR noload => cdr_pgsql.so                   ; PostgreSQL CDR Backend noload => cdr_syslog.so                  ; Customizable syslog CDR Backend noload => cdr_sqlite3_custom.so          ; SQLite3 Custom CDR Module noload => cdr_csv.so                     ; Comma Separated Values CDR Backend  ;  Channels -- noload => chan_mgcp.so           ; Media Gateway Control Protocol (MGCP) - Requires res_features.so noload => chan_skinny.so         ; Skinny Client Control Protocol (Skinny) - Requires res_features.so noload => chan_unistim.so         ; Unistim control protocol ; DON'T load the chan_modem.so, as they are obsolete in * 1.2 noload => chan_modem.so noload => chan_modem_aopen.so noload => chan_modem_bestdata.so noload => chan_modem_i4l.so ; Load either OSS or ALSA, not both ; By default, load no console driver noload => chan_alsa.so noload => chan_oss.so  ;  Codecs -- ;noload => codec_gsm.so           ; GSM/PCM16 (signed linear) Codec Translat - Requires N/A ;noload => codec_ilbc.so          ; iLBC/PCM16 (signed linear) Codec Translat - Requires N/A noload => codec_lpc10.so         ; LPC10 2.4kbps (signed linear) Voice Codec Translat - Requires N/A ;noload => codec_speex.so         ; Speex/PCM16 (signed linear) Codec Translat - Requires N/A  ;  Formats -- noload => format_au.so                   ; Sun Microsystems AU format (signed linear) - Requires N/A noload => format_gsm.so                  ; Raw GSM data - Requires N/A noload => format_h263.so                 ; Raw h263 data - Requires N/A noload => format_ilbc.so                 ; Raw iLBC data - Requires N/A noload => format_jpeg.so                 ; JPEG (Joint Picture Experts Group) Image - Requires N/A noload => format_mp3.so                  ; MP3 - Requires N/A  ;  Applications -- ;noload => app_directory_odbcstorage.so ;noload => app_voicemail_odbcstorage.so ;noload => app_adsiprog.so        ; Asterisk ADSI Programming Application -  Requires res_adsi.so ;noload => app_alarmreceiver.so   ; Alarm Receiver for Asterisk -  Requires N/A noload => app_chanspy.so         ; Listen to the audio of an active channel - Requires N/A ;noload => app_curl.so            ; ? - Requires N/A ;noload => app_festival.so        ; Simple Festival Interface - Requires N/A noload => app_flash.so           ; Flashes a Zap Trunk - Requires ? noload => app_getcpeid.so        ; Obtains and displays ADSI CPE ID for zapata. - Requires N/A noload => app_image.so           ; Sends an image on a channel. - Requires N/A noload => app_meetme.so          ; MeetMe conference bridge - Requires ? noload => app_mp3.so             ; Play an MP3 file or stream - Requires N/A noload => app_saycountpl.so      ; Polish counting grammar - Requires ? noload => app_zapateller.so      ; Block Telemarketers with Special Information Tone - Requires N/A noload => app_zapbarge.so        ;  Barges in on a specified zap channel - Requires ? ;noload => app_zapras.so          ;  Executes a RAS server using pppd on the given channel - Requires ? noload => app_zapscan.so         ; Scan Zap channels to monitor calls - Requires ? 

Идея и поиск решения

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

Естественно, для того чтобы не придумывать велосипед, был проведен предварительный анализ существующих решений. Вот, например, интересный концепт Поющей кружки для незрячих, который когда-то упоминался на Хабре. Идея отличная, но, похоже, ее так и не довели до стадии массового производства. Далее, на Ebay были найдены приемлемые варианты индикаторов уровня жидкости в чашке по цене около 20 долларов, учитывая доставку. Также на российских сайтах было пару вариантов по цене от 400 рублей. Что же касается нашего местоположения (Украина), то тут все оказалось значительно хуже — мы не нашли никаких вариантов (да, возможно, просто плохо искали).

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

Электрическая схема

Схема проста для безобразия. Полевой транзистор открывается тогда, когда оба контакта/клеммы оказываются в воде. Соответственно, начинает пищать звукоизлучатель, который запитан от 9-ти вольтовой батарейки. Энергопотребление такой схемы в рабочем режиме около 10 мА, а в режиме ожидания фактически стремится к нулю.

Комплектация

Итак, мы использовали:
1. Резервуар для стружек от точилки для карандашей в качестве корпуса — 5 грн
2. Две 9-ти вольтовых батарейки типа «Крона» (одна используется как питающий элемент, а со второй, уже не пригодной для использования по назначению, взят только разъем для питания) — 8 грн
3. Ручки из нержавеющей стали от чайного заварника для контакта с жидкостью — из личных запасов
4. Пьезоэлектрический звукоизлучатель (бузер) KPMB-G2306L — 14 грн
5. Полевой транзистор IRF540 — 4 грн
6. Два резистора: номиналом 500 кОм и 300 Ом — из личных запасов

Итого, общая сумма получилась 31 гривна (около 4$), что значительно меньше, чем стоимость всех ранее найденных готовых изделий.

Сборка

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

Сверху двухсторонним скотчем закрепили звукоизлучатель (хотя надежней было бы приклеить). И собрали на проводах всю схему. Все элементы были заизолированы термоусадкой.

Далее, все аккуратно уложили в корпус и залили при помощи клеевого пистолета.

Вот так выглядит готовый девайс.

Итоги

Осталось только показать сделанный индикатор уровня жидкости в деле.
Вот так он выглядит на чашке:

И, конечно, видео:

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

P.S. Напоследок хотелось бы добавить: мы часто не понимаем, насколько вещи, которые для нас элементарны, могут быть важны и сложны для других. Вот такое простое устройство хоть чуть-чуть облегчило жизнь человеку, а нам это, фактически, ничего не стоило. До нас никто не захотел ему помочь и это очень грустно. Помогайте людям если есть такая возможность, ведь не все они могут помочь себе сами.

Идентификация личности на основе данных о перемещениях

Не так давно в сети наткнулся на занимательную статью — аналитический отчет о том, как можно практически с 95 % гарантией идентифицировать личность пользователя мобильного устройства, зная только лишь 4 точки (по сути — базовые станции), через которые он выходил на связь через определенные промежутки времени (1,5-2 часа). В чем там оказалась суть…

Среди научных исследований в области управления доступом на основе данных о местоположении особо стоит отметить работу группы американских и английских исследователей [1], которые провели детальный анализ данных о перемещениях примерно 1,5 млн. абонентов сотовой сети связи в течении более чем полутора лет. Задачей анализа было выявить насколько уникальными являются маршруты передвижения абонентов и возможно ли, обладая лишь только данными о пребывании абонента в определенных точках в течении некоторого времени, достаточно точно идентифицировать его личность. Результатом исследования стал вывод, что, зная всего 4 пространственно-временных точки, можно с вероятностью в 95 % идентифицировать человека.

Как отмечают исследователи, данными о перемещениях абонентов уже давно пристально интересуются всевозможные коммерческие организации [1] и стараются заполучить их всеми возможными способами [2]. В таблице 4 представлен обзор способов определения местоположения и их точность.

Таблица 4
Способы определения местоположения и их точность

Как уже было отмечено, в исследовании использовалась выборка из данных о наблюдении перемещений 1,5 млн. абонентов в течение 15 месяцев [1], что гарантировало наличие репрезентативной выборки. В среднем, как отмечено, данные от каждого абонента передавались в среднем через 6500 антенн, телефон использовался абонентами в среднем 114 раз в месяц (звонки и передача SMS-сообщений). Точность измерения местоположения варьировалась от 0,15 км2 в городах до 15 км2 в сельской местности.

На рисунке 1 представлены основные результаты исследования в виде графика зависимости уникальности маршрута от количества пространственно-временных точек. Как видно из графика, при двух пространственно временных точках, уникальность маршрута (столбцы диаграммы зеленого цвета, где ) находится на уровне примерно 50 %, т.е. идентифицировать по двум точках абонента практически невозможно. При выборе 4 и более точек, уникальность маршрутов составляет уже более 95 %.

Рисунок 1 – Зависимость уникальности маршрута от количества
пространственно-временных точек

Кроме зависимости уникальности маршрутов от количества пространственно-временных точек исследовалась также зависимость от точности измерений по времени и по данным о местоположении. Результаты исследований представлены на рисунке 2. В частности, на диаграммах А (для 4 пространственно-временных точек) и D (для 10 пространственно-временных точек) рисунка 2 показаны зависимости уникальности маршрута от промежутков времени измерений данных о местоположении и количества сот базовых станций мобильной сети связи.

Рисунок 2 – Зависимость уникальности маршрута от временного (диаграмма B) и
пространственного (диаграмма C) разрешения (точности измерений)

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

Источники:

1. Jakob, E. B. Context-Aware User Authentication – Supporting Proximity-Based Login in Pervasive Computing / Jakob E. Bardram, Rasmus E. Kjaer, Michael F. Pedersen, – Berlin: UbiComp, LNCS2864. – № 2003. – P. 107-123.
2. Ильин С. Навигация без GPS. Как определить свои координаты по IP, GSM/UMTS и Wi-Fi / Степен Ильин, – Хакер, 2009. – № 4. – С. 124.