Alexander Mylnikov

19Апр/150

Геолокация без GPS

wifiЗдравствуйте!

Представляю публичную базу геопозиций телефонных вышек и Wi-Fi роутеров. Мне понадобилась стабильная и безлимитная база для приложения Android в котором нужна была точная геолокация из всех доступных источников (GPS, Wi-Fi, Mobile). Пришлось создать базу данных положений сотовых вышек и Wi-Fi. Всех заинтересовавшихся прошу под кат.

Связано с категорией: Без рубрики Читать полностью
15Апр/150

Определение местоположения по Wi-Fi (MAC, bssid) открытое API

Сегодня я хочу представить публичный API для определения местоположения по данным точки доступа Wi-Fi. В итернете достаточно много ресурсов предлагающих определение местоположения по данным Wi-Fi, однако все они либо платные, либо содержат ограничение на количество запросов, либо очень маленькие.

Данная база может быть интересна любым приложениям которые имеют географическую привязку с помощью Wi-Fi.

В своей базе я собрал все доступные публичные источники:

В данный момент база  содержит 10М Wi-Fi и постоянно наполняется новыми. Если у вас обширная база Wi-Fi буду рад ее добавить в свою базу [email protected].

API не содержит никаких скрытых лимитов или задержек. Данные предоставляются "как есть".

Описание публичного API:

Адреса обращения

https://api.mylnikov.org/wifi/main.py/get?bssid={wifi bssid}

https://api.mylnikov.org/wifi/main.py/get?bssid={wifi bssid}

{wifi bssid} - Bssid точки доступа (MAC адрес сетевой карты точки доступа)

Варианты:

  • A0:F3:C1:3B:6F:90
  • A0F3C13B6F90
  • a0f3c13b6f90
  • A0-F3-C1-3B-6F-90
  • a0-f3-c1-3b-6f-90

Пример:

https://api.mylnikov.org/wifi/main.py/get?bssid=A0:F3:C1:3B:6F:90

Варианты ответа:

{"result":200, "data":{"range": 140, "lan": "60.05205150", "lon": "30.33848000", "signal": "-80"}}
Поле "result" содержит значение 200 если Wi-Fi найден, в противном случае возвращается 404

Описание успешного ответа:

  • lan - широта
  • lon - долгота
  • signal - средний уровень сигнала
  • range - точность определения координаты

О любых ошибках или сложностях использования прошу обращаться ко мне по адресу почты [email protected].

Связано с категорией: Без рубрики Нет комментариев
7Апр/150

Public mobile cells database API implementation

Today i would like to introduce my public API implementation of mobile cells database. As a base point for my database I took public OpenCellID database. You can find there public API on The OpenCellID map. Unfortunately, they have very strict limitation for API key request amount. So I did my own API. Updates from OpenCellID I get each week. In my implementation no limits for requests or delays for responses, all for free.

But the real sources are not only public database of OpenCellID. I have a lot of sources as Google, Yandex, etc.

So here is the usage of my API:

http://api.mylnikov.org/mobile/main.py/get source of API. Parameters sends with GET request.

The API is able to contact via HTTPS as well https://api.mylnikov.org/mobile/main.py/get

There are 4 required parameters for request:

  1. mcc - Integer (Country code)
  2. mnc - Integer (Network operator code)
  3. cellid - Integer (Cell id)
  4. lac - Integer (Area or location code)

Example of usage:

http://api.mylnikov.org/mobile/main.py/get?mcc=250&mnc=02&cellid=200719106&lac=7840

250 is Russia, 02 - Megafon, 7840 - area code, 200719106 - cell id

Example of requests:

If cell fount you will get 200 in field result or 404 if request failed.

{

  • "result":200,
  • "data":{
    • "lan":"60.056793",
    • "radio":"UMTS",
    • "samples":49,
    • "mcc":250,
    • "mnc":2,
    • "lon":"30.385456",
    • "cellid":200719106,
    • "range":864

    }

}

{

  • "result":404,
  • "data":{}

}

 

I you need full database of cells in .sql format you can contact me and I will give a link to it. I will be happy to give you help via email [email protected]

Связано с категорией: Без рубрики Нет комментариев
5Апр/150

Публичная база телефонных станций мира OpenCellID открытое API

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

Это может быть полезно приложениям или порталам, которые по идентификаторам мобильной станции хотят получить ее геопозицию и тип. Данная база является копией The OpenCellID map, однако в официальной реализации есть ограничение на количество запросов и обязательно выпускать API ключ.

В моей реализации нет не лимитов, не ключей.

Данные обновляются еженедельно.

Реализация API

http://api.mylnikov.org/mobile/main.py/get адрес запросов передаются методом GET

Так же доступен по протоколу https://api.mylnikov.org/mobile/main.py/get

Для запроса есть 4 обязательных поля:

  1. mcc - Integer (Код страны)
  2. mnc - Integer (Код телефонного оператора)
  3. cellid - Integer (Код телефонной станции)
  4. lac - Integer (Код региона или Area, Location)

Пример:

http://api.mylnikov.org/mobile/main.py/get?mcc=250&mnc=02&cellid=200719106&lac=7840

Примеры ответов:

Если станция найдена в поле result приходит ответ 200, при ошибках возвращается код 404.

{

  • "result":200,
  • "data":{
    • "lan":"60.056793",
    • "radio":"UMTS",
    • "samples":49,
    • "mcc":250,
    • "mnc":2,
    • "lon":"30.385456",
    • "cellid":200719106,
    • "range":864

    }

}

{

  • "result":404,
  • "data":{}

}

Любые предложения по улучшений API приветствуются!

Связано с категорией: Без рубрики Нет комментариев
15Ноя/140

CSC Бызы данных, 9 дз

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

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

SELECT * FROM BusSummaryPerProject;

project_id  | new  | assigned | fixed | verified | not reproducible
1001          45     24         3       0          10
1002          56     10         37      104        15

Для упрощения можете считать, что множество статусов известно и не собирается меняться.

Во-вторых, для каждого статуса хочется видеть компоненту с максимальным, минимальным и медианным количеством багов с таким статусом. Например, если у нас 7 компонент и количество багов со статусом “new” в них распределено так:

C1 | 10
C2 | 50
C3 | 15
C4 | 30
C5 | 20
C6 | 25
C7 | 35

то в строке представления для статуса new должно быть:

SELECT * FROM StatisticsPerStatus WHERE status='new';

status | max_component | max_value | min_component | min_value | median_component | median_value
new      C2              50          C1              10          C6                 25

Если число компонент четное, то считайте медианой большее из двух возможных значений. Если медианное значение принадлежит нескольким компонентам, то добавьте лексикографическую сортировку по названию компоненты (так, если бы в примере выше в компоненте C4 было бы 25 багов, то медианой стала бы она, если бы в компоненте C5 было 25 багов, то медианой осталась бы C6, а если бы и в C4 и в C5 было бы 25 багов, то медианой стала бы C5)

Собсвтенно решение:

Пунт 1

Для вывода информаци по кадому проекту я построил впомогательно представление которое получает отношение "проект  - статус  - количество"

-- View: statustoproject

-- DROP VIEW statustoproject;

CREATE OR REPLACE VIEW statustoproject AS 
 SELECT count(bug.status_id) AS count, bug.status_id AS status, component.project_id AS project
   FROM bug
   JOIN bugcomponent ON bug.num = bugcomponent.bug_num
   JOIN component ON bugcomponent.component_id = component.id
  GROUP BY component.project_id, bug.status_id
  ORDER BY component.project_id, bug.status_id;

ALTER TABLE statustoproject
  OWNER TO postgres;

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

-- View: bussummaryperproject

-- DROP VIEW bussummaryperproject;

CREATE OR REPLACE VIEW bussummaryperproject AS 
 SELECT project.id AS project_id, COALESCE(( SELECT statustoproject.count
           FROM statustoproject
          WHERE statustoproject.project = project.id AND statustoproject.status = 1), 0::bigint) AS new, COALESCE(( SELECT statustoproject.count
           FROM statustoproject
          WHERE statustoproject.project = project.id AND statustoproject.status = 2), 0::bigint) AS assigned, COALESCE(( SELECT statustoproject.count
           FROM statustoproject
          WHERE statustoproject.project = project.id AND statustoproject.status = 3), 0::bigint) AS fixed, COALESCE(( SELECT statustoproject.count
           FROM statustoproject
          WHERE statustoproject.project = project.id AND statustoproject.status = 4), 0::bigint) AS verified, COALESCE(( SELECT statustoproject.count
           FROM statustoproject
          WHERE statustoproject.project = project.id AND statustoproject.status = 5), 0::bigint) AS "not reproducible"
   FROM project;

ALTER TABLE bussummaryperproject
  OWNER TO postgres;

Пункт 2

Самым сложным для меня было создать функцию медианы

CREATE OR REPLACE FUNCTION array_median(numeric[])
  RETURNS numeric AS
$$
    SELECT CASE WHEN array_upper($1,1) = 0 THEN null ELSE asorted[ceiling(array_upper(asorted,1)/2.0)] END
    FROM (SELECT ARRAY(SELECT ($1)[n] FROM
generate_series(1, array_upper($1, 1)) AS n
    WHERE ($1)[n] IS NOT NULL
            ORDER BY ($1)[n]
) As asorted) As foo ;
$$
  LANGUAGE 'sql' IMMUTABLE;
CREATE  AGGREGATE median(numeric) (
                  SFUNC=array_append,
                  STYPE=numeric[],
                  FINALFUNC=array_median
                );

Далее как и в первом примере я строю вспомогательное представление.

-- View: statustocomponent

-- DROP VIEW statustocomponent;

CREATE OR REPLACE VIEW statustocomponent AS 
 SELECT DISTINCT count(bug.status_id) AS count, bug.status_id AS status, component.id, component.title AS componentname
   FROM bug
   JOIN bugcomponent ON bug.num = bugcomponent.bug_num
   JOIN component ON bugcomponent.component_id = component.id
  GROUP BY component.id, bug.status_id
  ORDER BY component.id, bug.status_id;

ALTER TABLE statustocomponent
  OWNER TO postgres;

Далее строю нужно отношение.

-- View: statisticsperstatus

-- DROP VIEW statisticsperstatus;

CREATE OR REPLACE VIEW statisticsperstatus AS 
 SELECT bugstatus.value AS status, COALESCE(( SELECT statustocomponent.componentname
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id
          ORDER BY statustocomponent.count DESC, statustocomponent.componentname
         LIMIT 1), 'null'::character varying) AS max_component, COALESCE(( SELECT max(statustocomponent.count) AS max
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id), 0::bigint) AS max_value, COALESCE(( SELECT statustocomponent.componentname
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id
          ORDER BY statustocomponent.count, statustocomponent.componentname
         LIMIT 1), 'null'::character varying) AS min_component, COALESCE(( SELECT min(statustocomponent.count) AS min
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id), 0::bigint) AS min_value, COALESCE(( SELECT statustocomponent.componentname
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id AND statustocomponent.count::numeric = (( SELECT median(statustocomponent.count::numeric) AS median
                   FROM statustocomponent
                  WHERE statustocomponent.status = bugstatus.id))
          ORDER BY statustocomponent.componentname
         LIMIT 1), 'null'::character varying) AS median_component, COALESCE(( SELECT median(statustocomponent.count::numeric) AS median
           FROM statustocomponent
          WHERE statustocomponent.status = bugstatus.id), 0::numeric) AS median_value
   FROM bugstatus;

ALTER TABLE statisticsperstatus
  OWNER TO postgres;

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

Дамп базы dbhw9.sql

Связано с категорией: CSC Нет комментариев
9Ноя/140

CSC Базы данных, 8 дз

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

Баг №1: Improve overall performance дата | статус 01.09.2014 new 02.09.2014 assigned 25.09.2014 fixed 26.09.2014 assigned 06.10.2014 fixed 07.10.2014 verified

Мы не планируем выполнять такие отчеты часто, нам все же в основном будет интересен актуальный статус всех багов. Поэтому идея вносить дополнительный атрибут “дата” в таблицу Bug, или же наоборот, убирать атрибут status_id из таблицы Bug кажется не очень хорошей (но вы можете попробовать это сделать и оценить, насколько она в действительности плоха. Оценить можно написав, например, запрос, выдающий актуальные статусы всех багов)

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

UPDATE Bug SET status_id = 2 WHERE num=1

Поиск актуальных статусов, в идеале, тоже должен остаться прежним:

SELECT * FROM Bug

А историю клиенту хочется получать запросом вида

SELECT * FROM BugHistory WHERE num=1

где BugHistory — это отдельная таблица, или представление.

Задание решается достаточно просто.
А имеено: с помощью триггреров. Наша задача при добавлении бага начинать его историю, и при каждом UPDATE если статус был изменен вносить строку в таблицу истории. Далее приведены функции.

CREATE OR REPLACE FUNCTION log_update()
  RETURNS trigger AS
$BODY$
BEGIN
    IF NEW.status_id <> OLD.status_id THEN
        INSERT INTO BugHistory(num, date, status_id)
        VALUES (OLD.num, now()::date, NEW.status_id)    
    END IF;    
    RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
CREATE TRIGGER update_log_status
BEFORE UPDATE
ON bug
FOR EACH ROW
EXECUTE PROCEDURE log_update();
CREATE OR REPLACE FUNCTION log_insert()
  RETURNS trigger AS
$BODY$
BEGIN
    INSERT INTO bughistory(num, date, status_id)
    VALUES (NEW.num, now()::date, NEW.status_id);
    RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
CREATE TRIGGER insert_log_status
AFTER INSERT
ON bug
FOR EACH ROW
EXECUTE PROCEDURE log_insert();

 

Структура созданной таблицы bughistory

CREATE TABLE bughistory
(
  num integer,
  date date,
  status_id integer,
  id serial NOT NULL,
  CONSTRAINT pk_bhis PRIMARY KEY (id ),
  CONSTRAINT status_fk FOREIGN KEY (status_id)
      REFERENCES bugstatus (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT to_bug_table FOREIGN KEY (num)
      REFERENCES bug (num) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE bughistory
  OWNER TO postgres;

-- Index: fki_status_fk

-- DROP INDEX fki_status_fk;

CREATE INDEX fki_status_fk
  ON bughistory
  USING btree
  (status_id );

-- Index: fki_to_bug_table

-- DROP INDEX fki_to_bug_table;

CREATE INDEX fki_to_bug_table
  ON bughistory
  USING btree
  (num );

Так же прилагаю дамп базы данных dbhw8

Связано с категорией: CSC Нет комментариев
9Мар/140

Задача № 27. Чему равно центростремительное ускорение поезда, движущегося по закруглению радиусом 1000мсо скоростью 54 км/ч? В какую сторону направлено это ускорение?

Условие задачи: Задача № 27. Чему равно центростремительное ускорение поезда, движущегося по закруглению радиусом 1000мсо скоростью 54 км/ч? В какую сторону направлено это ускорение?

Задача из решебника «Физика. 7-й и 8-й классы» С.В Громов, Н.А. Родина

за 2000 год
Онлайн решебник по физике
за  7 класс
Глава 1
→ номер 27

Задача № 27. Чему равно центростремительное ускорение поезда, движущегося по закруглению радиусом 1000м со скоростью 54 км/ч? В какую сторону направлено это ускорение?

Решение:

8class1-36

Связано с категорией: ГДЗ Нет комментариев
4Фев/140

Возможность отправки почты с корпоративного домена из личного почтового клиента

Объясняется 2 способа.

  1. Простой (предпочтительный)
  2. Профессиональный

1-й способ.

У вас есть адрес вида [email protected]

С вашего ящика идет переадресация на личный e-mail с созданием копии в корпоративном ящике.

Во многих популярных почтовых сервисах (Mail.ru, Yandex, Gmail.com) есть возможность изменения адреса отправителя. Наша задача изменить адрес отправителя на корпоративный e-mail. Важно понимать, что при отправке письма можно выбирать адрес отравителя.

Рассмотрим алгоритм изменения адреса отправителя на примере почтовой службы Gmail.com

i1

Открытие настроек

i2

Открытие настроек

Раздел "Аккаунт"

Раздел "Аккаунт"

 

Добавить свой аккаунт

Добавить свой аккаунт

 

Ввод персональных данных

Ввод персональных данных

i6

Выбор метода подтверждения

i7

Отправка подтверждения на имеил.

Затем на свою личную почту вы получаете письмо с разрешением использования корпоративной почты в качестве адреса отправления.

Получающие вашу корреспонденцию, будут видеть корпоративный адрес.

2й способ

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

Рассматриваем на примере Gmail.com

Открытие настроек

Открытие настроек

Открытие настроек

Открытие настроек

Раздел "Аккаунт"

Раздел "Аккаунт"

Добавить свой акканут

Добавить свой акканут

Ввод персональных данных

Ввод персональных данных

 

Настройки подключения к серверу SMTP
server: smtp.yandex.ru
login:    Ваша корпоративная почта
pass:     Пароль от почтового ящика. Узнать его можно у руководителя отдела

Ввод настроек SMTP

Ввод настроек SMTP

Ожидание подтвеждения

Ожидание подтвеждения

Связано с категорией: Без рубрики Нет комментариев