Как я убил 3 вечера

Неделю назад я ушел в отпуск, но, как и положено, от ноутбука не отрывался. Едва ли не в первый вечер я думал, чем бы заняться, чтобы время прошло с пользой. В распоряжении находились HTC Desire (с андроидом на борту) и свободный сервер, выхваченный по акции.

Открыв свои старые записи я обнаружил наброски «ключевиков» под заголовком «WiFi». Суть проекта — автоматический сбор информации об открытых WiFi сетях в своем городе с желанием распространить проект на весь мир (аха, конечно). Задачей минимум являлось изучение новых технологий — чем я и занялся.
На самом-то деле, все было просто только в базовом варианте — запустить на Адроиде демон, который будет постоянно сканировать новые WiFi сети и отправлять их на сервер. В расширенной-же версии дополнительно хотелось анализировать качество 3G-сигнала (по скорости соединения, конечно). В качестве сервера можно было использовать GAE.

Я начал изучение проблемы с Android. Поскольку родным языком для меня является русский python, было решено использовать sl4a для обеспечения работы этого языка на Android.

Что же позволяют Python + SL4A?

Я смог вытащить из GPS: широту, долготу, время, точность положения. Высота, почему-то, всегда равна нулю.
Методы, доступные из python (не знаю, как в Java) позволяют узнать следующую информацию о WiFi:
— список доступных для подключения WiFi-сетей
— MAC-адрес роутера для каждой сети
— качество сигнала (level) сети
— частота, на которой работает сеть
— метод авторизации и способ шифрования (capabilities), используемые при подключении

Примерный код клиента можно посмотреть здесь. Если смотреть лень, то сообщаю — получился он весьма коротким (125 строк при наличии режима debug и полном несоблюдении PEP).

Сервер

Как я уже говорил, я хотел использовать GAE для серверной части. С созданием приложения, регистрацией и «Hello, World!» проблем не возникло. А вот в части выборок из базы возникли некоторые проблемы. ГЕО-приложение, которое должно уметь делать сложные выборки на GAE строить оказалось сложно. Конечно, было найдено несколько костыльных решений (IMHO, разумеется), но первое впечатление было испорчено.

Плюс ко всему — неизвестно, что дальше будет с проектом, а переделывать серверную часть не очень хотелось (как и искать нетривиальные решения задач).

Далее было решено использовать RPC-модуль для Django. У меня было своё решение для RPC-сервисов (я о нем уже писал), но я часто рассматриваю «другие» варианты для поиска идей для реализации «хотелок».

В качестве модуля для реализации RPC в Django рекомендую rpc4django — самое оптимальное решение, которое я смог найти. Плюсов очень много, но главный — одним декоратором функция превращается в метод, доступный для Remote Call.

В целом — мне крайне понравилась работа с Django, но в для данного проекта я решил использовать «своё родное». Хотя я уверен, опыт работы с данным фреймворком мне еще пригодится.

Данные

Я уже говорил о том, какие данные я смог получить от Android и передать на сервер. Но не говорил, какие данные хранятся.

Во-первых, я столкнулся с тем фактом, что не всегда wi-fi сети получить удается корректно. Часто, ssid имеет нулевую длину (при этом — все остальные свойства соединения так же пустые).

Во-вторых, возникает проблема — что делать с одними и теми же точками? Решение было тривиально — в качестве идентификатора сети использовать не SSID, а BSSID (т.е. MAC-адрес роутера).

Стоит так же отметить, что одни и те же BSSID можно обнаружить с разных точек удаления от самого роутера, и, как следствие, получить разные координаты. Эта проблема была решена следующим образом: в базе хранятся не только координаты сети (фактически — координаты точки, сигнал в которой максимален для данного BSSID), но и max/min значения широты и долготы. Эти данные позволяют (в теории) определить ареал сети более-менее точно.

Третьей «модернизацией в инновациях» стала актуальность точки, определяемая последним обнаружением этой сети.

Сбор данных

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

Собранные точки вы можете посмотреть здесь.

Итоги

Вот такие fast-проекты позволяют изучить то, на что в рабочем графике вряд ли получится выделить время. Сразу отвечу на вопросы (включаем режим телепата):

Будет ли проект жить?
Честно говоря — не знаю. Проект делался just-for-fun, но данные по точкам в Казани я обновлять буду — это факт. Если кому-то проект поможет воспользоваться бесплатным интернетом — я буду рад.

Какие планы по развитию?
См. предыдущий пункт. Я буду рад, если ко мне обратятся и попросят API (оно достаточно простое) с целью реализовать клиента для мобильных устройств. Дело не столько в сборе точек, сколько в отображении — ведь я реализовал только web-версию, которая не предоставляет всего функционала, который можно придумать.

Что бы я хотел сделать?
Во-первых, нативную реализацию клиента под Android, ведь связка python+sl4a до клиента вряд ли дойдет.
Во-вторых, клиента для мобильных устройств с возможностью поиска ближайшей открытой бесплатной точки.
В-третьих, мне крайне интересен вопрос определения адреса по координатам и каталогизацию всего накопленного добра на сайте/в приложении.

Что я хотел сказать этим постом?
Ну, не знаю. Хотел поделиться своим проектом (но для «Я пиарюсь» мой недосервис явно не дотягивает).
Хотел дать идею людям, способным и желающим реализовать проект подобного рода для масс. Пусть даже не в рамках уже написанного кода и собранной базы. Кстати, я с удовольствием поделюсь базой в xml-формате со всеми страждущими.

PS: Для тех, кто «ниасилил» — ссылка на прототип сервиса.
Спасибо за внимание :)