[Из песочницы] Что происходит с интернетом «ТЕЛЕ-2»

Привет всем, хабровчане!

Собственно, к написанию этой статьи меня подтолкнули часто срабатывающие триггеры системы мониторинга Zabbix на падение скорости в сети «ТЕЛЕ-2». На удаленных объектах, к которым невозможно провести оптику, организован проброс портов регистратора через USB модемы, перепрошитые под любых операторов. К слову, наша организация попутно использует в своих нуждах и мобильный интернет «Мегафон», но с ним подобных проблем не наблюдается. А проблема следующая: начиная примерно с обеда 07.08.2019, оповещение заббикса о нулевой скорости выполнения веб-сценария на страницах видео регистраторов стало столь частым, что почта отправителя, указанная в оповещении заббикса, стала воспринимать письма триггеров как спам и не доставлять их получателю, то-есть мне. Немаловажно и то обстоятельство, что в целом фоновое состояние проблемных сетей в целом удовлетворяет, а падения кратковременные, но сразу в ноль.

На момент написания статьи (19:25 10.08.2019) частота падения скорости стала проявляться реже, однако если падение и происходит, то это именно регистраторы, проброшенные через «ТЕЛЕ-2». Тут очень важно отметить, что речь идет обо всей московской области. Даже увеличение периода между проверками до 2 минут практически не изменило ситуацию. Также абсолютно не помогло возвращение дефолтного заббикс-сервер-конфига (ну, мало ли). Звонок на горячую линию «ТЕЛЕ-2» не принес никаких объяснений происходящему, кроме совета попробовать выставить в параметрах модема смешанный режим (видимо речь шла о «LTE+UMTS»), чего ранее не требовалось, а если и требовалось, то не на всех объектах с оператором «ТЕЛЕ-2» одновременно, да и проблема явно лежит глубже, нежели в выборе протокола. И я, конечно же, в понедельник свяжусь с корпоративным отделом «ТЕЛЕ-2» на предмет выяснения природы такого поведения сети, но сильно сомневаюсь, что ТАМ захотят себя как-то дискредитировать. Поэтому данная паста как бы предостерегает, а заодно вопрошает: «не замечал ли кто подобного в своем мобильном интернете „ТЕЛЕ-2“ или Заббиксе?»

В таком вот з@ср@нном состоянии находится папка для приема заббикс-оповещения (и так 4 дня):

Карта Заббикса с видео регистраторами (если в скрине почты не понятно, что оператор «ТЕЛЕ-2», то на карте это очевидно):

Ну и вишенкой на торте для всех ранее приведенных фактов является синхронность падений в Москве и ближайшем подмосковье, независимо от их географии. Сюда не вошли совсем дальние точки типа Долматово и Ферма, хотя, просто посмотрите как зубасто выглядят их графики:

Вот время падения в Сгонниках:

Вот район размещения Сгонников:

Примерно во столько же падение в Строгино:

Местонахождение Строгино:

И наконец падение в Щербинке:

Она здесь:

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

Let's block ads! (Why?)

[Перевод] Тренинг Cisco 200-125 CCNA v3.0. День 13. Настройка VLAN

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

Откроем окно программы Cisco Packer tracer с нарисованной мною логической топологией нашей сети.

К первому свитчу SW0 подключены 2 компьютера PC0 и PC1, объединенные в сеть VLAN10 с диапазоном IP-адресов 192.168.10.0/24. Соответственно, IP-адреса этих компьютеров будут 192.168.10.1 и 192.168.10.2. Обычно люди идентифицируют номер VLAN по третьему октету IP-адреса, в нашем случае это 10, однако это не обязательное условие обозначение сетей, вы можете назначить любой идентификатор VLAN, однако такой порядок принят в крупных компаниях, потому что облегчает настройку сети.

Далее расположен свитч SW1, который подключен к сети VLAN20 с IP-адресом 192.168.20.0/24 с двумя ноутбуками Laptop1 и Laptop2.

VLAN10 расположена на 1 этаже офиса компании и представляет собой сеть руководства отдела продаж. К этому же свитчу SW0 подключен ноутбук Laptop0 маркетолога, который относится к VLAN20. Эта сеть распространяется на 2 этаж, где расположены другие сотрудники, и она соединена с отделом продаж, который может быть расположен в другом здании или на 3 этаже этого же офиса. Здесь установлены ещё 3 компьютера – PC2,3 и 4, которые являются частью сети VLAN10.

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

Давайте приступим к её настройке и начнем с компьютера PC0. Кликнув по иконке, войдем в сетевые настройки компьютера и введем IP-адрес 192.168.10.1 и маску подсети 255.255.255.0. Я не ввожу адрес шлюза по умолчанию, потому что он нужен для выхода из одной локальной сети в другую, а в нашем случае мы не будем разбираться с настройками 3 уровня OSI, нас интересует только 2 уровень, и мы не собираемся рассматривать маршрутизацию трафика в другую сеть.

Мы собираемся настраивать интрасеть и только те хосты, которые в неё входят. Затем мы перейдем к компьютеру PC2 и проделаем то же самое, что и для первого ПК. Теперь проверим, смогу ли я пропинговать PC1 с компьютера PC0. Как видите, пинг проходит, и компьютер с IP-адресом 192.168.10.2 уверенно возвращает пакеты. Таким образом, мы успешно установили связь между PC0 и PC1 через свитч.

Чтобы понять, почему нам это удалось, зайдём в настройки свитча и посмотрим на таблицу VLAN.

Технически данный свитч имеет 5 VLAN: VLAN1 по умолчанию, а также 1002,1003,1004 и 1005. Если посмотреть на 4 последние сети, можно увидеть, что они не поддерживаются и обозначены unsupported. Это виртуальные сети старой технологии – fddi, fddinet, trnet. В настоящее время они не используются, но согласно техническим требованиям до сих пор включаются в новые устройства. Таким образом, фактически наш свитч имеет по умолчанию всего одну виртуальную сеть – VLAN1, поэтому все порты любого свитча Cisco «из коробки» настроены на эту сеть. Это 24 порта Fast Ethernet и 2 порта Gigabit Ethernet. Это значительно облегчает совместимость новых свитчей, потому что по умолчанию все они являются частью одной и той же VLAN1.

Мы должны переназначить порты, которые по умолчанию настроены на работу с VLAN1, на работу с VLAN10. Packet Tracer показывает, что в нашем случае это порты Fa0 и Fa0/2.

Вернемся к свитчу SW0 и настроим два эти порта. Для этого я использую команду configure terminal чтобы зайти в режим глобальной конфигурации, и ввожу команду настройки данного интерфейса – int fastEthernet 0/1. Мне нужно установить для этого порта режим работы access, потому что это access-порт, и я использую команду switchport mode access.

Этот порт конфигурируется как статический access-порт, но если я подключу к нему другой свитч, то благодаря использованию протокола DTP он перейдет в динамический режим trunk. По умолчанию этот порт принадлежит VLAN1, поэтому мне нужно использовать команду switchport access vlan 10. При этом система выдаст нам сообщение о том, что VLAN10 не существует и её необходимо создать. Если помните, в базе данных VLAN у нас существует только одна сеть – VLAN1, и никакой сети VLAN10 там нет. Но мы запросили свитч предоставить доступ к VLAN10, поэтому получили сообщение об ошибке.

Поэтому нам необходимо создать VLAN10 и приписать к ней этот access-порт. После этого, если зайти в базу данных VLAN, можно увидеть созданную только что VLAN0010, которая находится в активном состоянии и которой принадлежит порт Fa0/1.

Мы не вносили никаких изменений в компьютер, а просто настроили порт свитча, к которому он подключен. Теперь попробуем пропинговать IP-адрес 192.168.10.2, что мы удачно проделали несколько минут назад. У нас ничего не получилось, потому что порт, к которому подключен PC0, теперь относится к сети VLAN10, а порт, связанный с компьютером PC1, по прежнему принадлежит VLAN1, и никакой связи между этими двумя сетями не существует. Для того, чтобы установить связь между этими компьютерами, необходимо настроить оба порта на работу с VLAN10. Я снова вхожу в режим глобальной конфигурации и проделываю аналогичные действия для switchport f0/2.

Посмотрим ещё раз на таблицу VLAN. Теперь мы видим, что сеть VLAN10 настроена на портах Fa0/1 и Fa0/2. Как видим, теперь пинг проходит успешно, потому что оба порта свитча SW0, к которым подключены устройства, принадлежат одной и той же сети. Давайте попробуем изменить имя сети, чтобы обозначить её предназначение. Если мы хотим внести какие-либо изменения в VLAN, мы должный войти в настройку этой сети.

Для этого я набираю команду vlan 10, и вы видите, что подсказка командной строки поменялась со Switch (config) # на Switch (config-vlan) #. Если ввести знак вопроса, система покажет нам только 3 возможных команды: exit, name и no. Я могу назначить имя сети с помощью команды name, возвратить команды к состоянию по умолчанию, набрав no или сохранить внесенные изменения, использовав команду exit. Поэтому я ввожу команды name SALES и exit.

Если посмотреть базу данных VLAN, можно убедиться, что наши команды исполнены и бывшая VLAN10 теперь носит название SALES – отдел продаж. Итак, мы подсоединили 2 компьютера нашего офиса к созданной сети отдела продаж. Теперь нужно создать сеть для отдела маркетинга. Для того, чтобы подсоединить к этой сети ноутбук Laptop0, нужно войти в его сетевые настройки и внести IP-адрес 192.168.20.1 и маску подсети 255.255.255.0, шлюз по умолчанию нам не нужен. Затем нужно вернуться к настройкам свитча, войти в настройки порта командой int fa0/3 и ввести команду switchport mode access. Следующей командой будет switchport access vlan 20.

Мы снова получаем сообщение о том, что такой VLAN не существует и её необходимо создать. Можно пойти другим путем – я выйду из настройки порта Switch (config-if), зайду в Switch (config) и введу команду vlan 20, тем самым создав сеть VLAN20. То есть можно сначала создать сеть VLAN20, присвоить ей имя MARKETING, сохранить изменения командой exit, а затем настраивать под неё порт.

Если зайти в базу VLAN командой sh vlan, можно увидеть созданную нами сеть MARKETING и соответствующий ей порт Fa0/3. Я не смогу пропинговать компьютеры с этого ноутбука по двум причинам: у нас имеются разные VLAN и наши устройства принадлежат к разным подсетям. Так как они принадлежат разным VLAN, свитч будет отбрасывать пакеты ноутбука, направленные в другую сеть, потому что у него нет порта, принадлежащего VLAN20.

Как я говорил, компания расширяется, маленького офиса на первом этаже не хватает, поэтому она размещает отдел маркетинга на 2-м этаже здания, устанавливает там компьютеры для 2-х сотрудников и хочет обеспечить связь с отделом маркетинга на первом этаже. Для этого нужно сначала создать транк между двумя свитчами – портом Fa0/4 первого свитча и портом Fa0/1 второго свитча. Для этого я вхожу в настройки SW0 и ввожу команды int f0/4 и switchport mode trunk.

Существует команда инкапсуляции switchport trunk enc, однако в новых свитчах она не применяется, потому что по умолчанию они используют технологию инкапсуляции по протоколу 802.1q. Однако старые модели свитчей Cisco использовали проприетарный протокол ISL, который больше не применяется, так как теперь все свитчи понимают протокол .1Q. Таким образом, у вас больше нет необходимости в использовании команды switchport trunk enc.

Если сейчас зайти в базу данных VLAN, можно увидеть, что из неё исчез порт Fa0/4. Это потому, что в данной таблице указаны только access-порты, которые относятся к конкретной VLAN. Для того, чтобы увидеть транк-порты свитча, необходимо использовать команду sh int trunk.

В окне командной строки мы видим, что порт Fa0/4 включен, осуществляет инкапсуляцию по протоколу 802.1q и принадлежит к native vlan 1. Как мы знаем, если этот транк-порт принимает нетегированный трафик, он автоматически направляет его в сеть native vlan 1. На следующем уроке мы поговорим о настройке native vlan, пока что просто запомните, как выглядят настройки транка для данного устройства.

Теперь я перехожу ко второму свитчу SW1, вхожу в режим настроек int f0/1 и повторяю последовательность настройки порта аналогично предыдущему случаю. Два порта Fa0/2 и Fa0/3, к которым подсоединены ноутбуки сотрудников отдела маркетинга, необходимо настроить на режим access и приписать к сети VLAN20.

В предыдущем случае мы индивидуально настраивали каждый порт свитча, а сейчас я хочу показать вам, как ускорить этот процесс, используя шаблон командной строки. Можно ввести команду для настройки диапазона интерфейсов int range f0/2-3, в результате чего запрос командной строки примет вид Switch (config-if-range)#, и вы сможете ввести один и тот же параметр или применить одну и ту же команду к указанному диапазону портов, например, одновременно для 20 портов.

В предыдущем примере мы несколько раз использовали одни и те же команды switchport mode access и switchport access vlan 10 для нескольких портов свитча. Эти команды можно вводить однократно, если использовать диапазон портов. Сейчас я введу команды switchport mode access и switchport access vlan 20 для выбранного диапазона портов.

Поскольку сеть VLAN20 пока не существует, система создаст её автоматически. Я набираю exit для сохранения внесенных изменений и прошу показать мне таблицу VLAN. Как видите, теперь порты Fa0/2 и Fa0/3 являются частью только что созданной VLAN20.

Теперь я настрою IP-адреса ноутбуков на втором этаже нашего офиса: Laptop1 получит адрес 192.168.20.2 и маску подсети 255.255.255.0, а Laptop2 получит IP-адрес 192.168.20.3. Проверим работоспособность сети, пропинговав первый ноутбук со второго. Как видите, пинг проходит удачно, потому что оба устройства являются частью одной VLAN и подсоединены к одному и тому же свитчу.

Однако ноутбуки отдела маркетинга на первом и втором этажах присоединены к разным свитчам, хотя находятся в одной сети VLAN. Проверим, как обеспечивается связь между ними, для этого я пропингую с Laptop2 ноутбук на первом этаже, имеющий IP-адрес 192.168.20.1. Как видите, все работает без проблем несмотря на то, что ноутбуки подсоединены к разным свитчам. Связь осуществляется благодаря тому, что оба свитча соединены транком.

Могу ли я установить связь между Laptop2 и компьютером PC0? Нет, не могу, потому что они принадлежат к разным VLAN. Теперь проведем настройку сети компьютеров PC2,3,4, для чего сначала создадим транк между вторым свитчем Fa0/4 и третьим свитчем Fa0/1.

Я захожу в настройки SW1 и набираю команду config t, после чего вызываю int f0/4, затем ввожу команды switchport mode trunk и exit. Аналогичным образом я настраиваю третий свитч SW2. Мы создали транк, и вы видите, что после того, как настройки вступили в силу, цвет портов поменялся с оранжевого на зеленый. Теперь необходимо настроить порты Fa0/2,0/3,0/4, к которым подсоединены компьютеры отдела продаж, принадлежащие сети VLAN10. Для этого я вхожу в настройки свитча SW2, выбираю диапазон портов f0/2-4 и применяю к ним команды switchport mode access и switchport access vlan 10. Поскольку на этих портах сеть VLAN10 отсутствует, она создается системой автоматически. Если посмотреть на базу данных VLAN этого свитча, можно увидеть, что теперь порты Fa0/2,0/3,0/4 принадлежат сети VLAN10.

После этого необходимо настроить сеть для каждого из этих 3-х компьютеров, введя IP-адреса и маски подсети. PC2 получает адрес 192.168.10.3, PC3 – адрес 192.168.10.4, а PC4 – IP-адрес 192.168.10.5.

Чтобы ответить на вопрос, работает ли наша сеть, пропингуем компьютер PC0 на первом этаже с компьютера PC4, расположенного на 3-м этаже или в другом здании. Пингование окончилось неудачей, так что попробуем разобраться, почему нам не удалось это сделать.

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

Когда мы посылаем пакет с компьютера PC4 на свитч SW2, он видит, что пакет поступает на порт Fa0/4. Свитч проверяет свою базу данных и обнаруживает, что порт Fa0/4 относится к сети VLAN10. После этого свитч тегирует фрейм номером сети, то есть прикрепляет к пакету трафика заголовок VLAN10, и отправляет его по транку второму свитчу SW1. Этот свитч «читает» заголовок и видит, что пакет предназначен для сети VLAN10, заглядывает в свою базу данных VLAN и, обнаружив, что никакой VLAN10 там нет, отбрасывает пакет. Таким образом, устройства PC2,3 и 4 без проблем могут общаться друг с другом, но попытка установить связь с компьютерами PC0 и PC1 оканчивается неудачей, потому что свитч SW1 ничего не знает о сети VLAN10.

Мы можем легко исправить эту проблему, зайдя в настройки SW1, создав сеть VLAN10 с помощью команды vlan 10 и введя её название MARKETING. Попробуем повторить пингование – вы видите, что первые три пакеты отбрасываются, а четвертый проходит удачно. Это объясняется тем, что сначала свитч проверял IP-адреса и определял MAC-адрес, это заняло определенное время, поэтому три первых пакета были отброшены таймаутом. Сейчас связь установлена, потому что свитч дополнил свою таблицу MAC-адресов и направляет пакеты прямо на требуемый адрес.
Всё, что я сделал для устранения проблемы – это зашел в настройки промежуточного свитча и создал там сеть VLAN10. Таким образом, даже если сеть непосредственно не связана со свитчем, он все равно должен знать обо всех сетях, участвующих в сетевых соединениях. Однако если в вашей сети имеется сотня свитчей, вы физически не сможете зайти в настройки каждого и вручную сконфигурировать идентификаторы VLAN. Вот почему мы используем протокол VTP, настройку которого рассмотрим на следующем видеоуроке.

Итак, сегодня мы рассмотрели все, что планировали: как создавать VLAN, как присваивать порты VLAN и как просматривать базу данных VLAN. Для создания сетей мы входим в режим глобальной конфигурации свитча и используем команду vlan <номер>, мы также можем присвоить имя созданной сети с помощью команды name <имя>.

Мы также можем создать VLAN другим путем, войдя в режим интерфейса и использовав команду switchport access vlan <номер>. В случае отсутствия сети с таким номером она будет создана системой автоматически. Не забывайте использовать команду exit после внесения изменений в первоначальные настройки, иначе они не сохранятся в базе данных VLAN. Далее вы можете приписать порты к конкретным сетям VLAN, используя соответствующие команды.

Команда switchport mode access переводит интерфейс в статический режим access-port, после чего номер соответствующей VLAN приписывается порту командой switchport access vlan <номер>. Для просмотра базы данных VLAN используется команда show vlan, которую следует ввести в пользовательском режиме EXEC. Для просмотра списка транк-портов нужно использовать команду show int trunk.

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)

Сначала фронт, а потом бэк (когда-нибудь)

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

Разработка сложного функционала требует тонкой координации усилий коллектива инженеров. И одним из важнейших моментов является вопрос распараллеливания задач.

Возможно ли избавить фронтовиков от необходимости ждать реализацию бэка? Есть ли способ распараллелить разработку отдельных фрагментов UI?

Тему распараллеливания задач в веб-разработке мы и рассмотрим в этой статье.

Проблема

Итак, давайте для начала обозначим проблему. Представьте, что у вас есть матерый продукт (интернет сервис), в котором собрано довольно много разных микросервисов. Каждый микросервис в вашей системе — это своего рода мини-приложение интегрированное в общую архитектуру и решающее какую-то конкретную проблему пользователя сервиса. Представьте, что сегодня утром (в последний день спринта) к вам обратился Product Owner по имени Василий и обявил: "В следующем спринте мы начинаем пилить Импорт Данных, который сделает пользователей сервиса еще счастливее. Он позволит пользователю в сервис залить сразу стопиццот дофигаллиардов позиций из дремучей 1С!".

Представьте что вы менеджер или тимлид и слушаете все эти восторженные описания счастливых пользователей не с позиции бизнеса. Вы оцениваете сколько трудозатрат все это потребует. Как хороший менеджер вы прикладываете все усилия, чтобы уменьшить аппетиты Василия на скоуп задач для MVP (здесь и далее, Minimum Viable Product). При этом два главных требования для MVP — способность системы импорта выдержать большую нагрузку и работа в фоне, выкинуть нельзя.

Вы понимаете, что традиционным подходом, когда все данные обрабатываются в пределах одного запроса пользователя, обойтись не удастся. Тут придется городить огород всяких фоновых воркеров. Придется завязываться на Event Bus, думать о том как работает балансировщик нагрузки, распределенная БД и т.п. В общем все прелести микросервисной архитектуры. В итоге вы делаете вывод, что разработка бэкенда под эту фичу затянется, в гадалки не ходи.

Автоматом встает вопрос: "A что будут делать фронтовики все это время пока нет никакого API?".

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

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

Agile пытается нам помочь

Гибкие методологии дают мудрый совет. "Начните со скейта и покажите пользователю. Вдруг ему понравится. Если понравилось, продолжайте в том же духе, прикручивайте новые фишки."
Но что, если пользователю сразу нужен как минимум мотоцикл, причем уже через две-три недели? Что если для начала работы над фасадом мотоцикла нужно хотя бы определиться с габаритами мотора и размерами ходовой части?

Как сделать так, чтобы реализация фасада не откладывалась до тех пор, пока не появится определенность с остальными слоями приложения?

В нашей ситуации лучше применить другой подход. Лучше сразу начать делать фасад (фронт), чтобы убедиться в корректности изначального представления об MVP. С одной стороны, подсунуть Product Owner'у Василию декоративный фасад, за которым ничего нет, кажется читерством, надувательством. С другой стороны, мы очень быстро получаем таким образом фидбек именно о той части функционала, c которой в первую очередь столкнется пользователь. У вас может быть неимоверно крутая архитектура, но если удобства использования нет, то какульками забросают все приложение целиком, не разбираясь в деталях. Поэтому мне кажется более важным выдать максимально функциональный UI как можно быстре, вместо того, чтобы синхронизировать прогресс фронтовой части с бэкендом. Нет смысла выдавать на пробу недоделанный UI и бэк, функционал которых не удовлетворяет главным требованиям. В то же время выдача 80% требуемого функционала UI, но без работающего бэка, вполне может оказаться профитной.

Немного технических деталей

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

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

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

Самый эффективный способ оповещения — WebSocket'ы. С фронта через Websocket с определенным периодом будут отправляться запросы на получения текущего статуса фоновоой обработки данных. Для фоновой обработки данных нам понадобятся фоновые обработчики, распределенная очередь команд, Event Bus и т.д.

Dataflow видется следующим (для справки):

1. Через файловый API браузера просим пользователя выбрать нужный файл с диска.
2. Через AJAX отправляем файл в бэкенд.
3. Ожидаем окончания валидации и распарсивания файла с данными (опрашиваем статус фоновой операции через Websocket).
4. По окончании валидации грузим подготовленные к импорту данные и рендерим их в таблице на странице импорта.
5. Пользователь редактирует данные, исправляет ошибки. По нажатию на кнопку внизу страницы отправляем исправленные данные в бэкенд.
6. Опять на клиентской стороне запускаем периодический опрос статуса фоновой операции.
7. До окончания текущего импорта у пользователя не должно быть возможности запустить новый импорт (даже в соседнем окне браузера или на соседнем компьютере).

План разработки

Мокап UI vs. Прототип UI

Давайте сразу обозначим разницу между Wireframe, Mockup, Prototype.

На рисунке выше изображен Wireframe. Это просто рисунок (в цифре или на бумаге — не суть важно). С другими двумя понятиями сложнее.

Мокап — это такая форма представления будущего интерфейса, которая используется только в качестве презентации и в последствии будет заменена полностью. Эта форма в будущем будет отложена в архив как образец. Реальный интерфейс будет делаться с помощью других инструментов. Мокап можно сделать в векторном редакторе с достаточной детализацией дизайна, но потом фронтенд-разработчики просто отложат его в сторону и будут подглядывать на него как образец. Мокап может быть сделан даже в специализированных браузерных конструкторах и снабжен ограниченной интерактивностью. Но судьба его неизменна. Он станет образцом в альбоме Design Guide.

Прототип же создается с помощью тех же инструментов, что и будущий интерфейс пользователя (например, React). Код прототипа размещается в общем репозитарии приложения. Он не будет заменен, как это происходит с мокапом. Сначало его используют для проверки концепции (Proof of Concept, PoC). Потом, если он пройдет проверку, его начнут развивать, постепенно превращая в полноценный интерфейс пользователя.

Теперь ближе к делу...

Представим, что коллеги из цеха дизайна представили нам артефакты своего творческого процесса: mockup'ы будущего интерфейса. Наша задача спланировать работу так, чтобы как можно скорее сделать параллельную работу фронтовиков возможной.

Как составление алгоритма начинается с блок-схемы, так и создание прототипа начинаем с минималистичного Wireframe'а (см. рисунок выше). На этом Wireframe мы делим будущий функционал на крупные блоки. Главный принцип тут — фокусировка ответственности. Не следует разделять один кусок функциональности на разные блоки. Мухи идут в один блок, а котлеты в другой.

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

Получаем такую иерархию веток в git:

master ---------------------- >
  └ feature/import-dev ------ >

Ветка "import-dev" будет играть роль development бранча для всей фичи. У этой ветки желательно закрепить одного ответственного человека (мэйнтейнера), который мержит атомарные изменения от всех параллельно работающих над фичей коллег. Также желательно не делать прямых каммитов в эту ветку, чтобы уменьшить шанс конфликтов и неожиданных изменений при мерже в эту ветку атомарных пулл реквестов.

Т.к. у нас на этот момент уже созданы компоненты для основных блоков на странице, то можно уже сразу создавать отдельные ветки под каждый блок UI. Финальная иерархия может выглядеть так:

master ----------------------- >
  └ feature/import-dev ------- >
    ├ feature/import-head ---- >
    ├ feature/import-filter -- >
    ├ feature/import-table --- >
    ├ feature/import-pager --- >
    └ feature/import-footer -- >

Примечание: неважно в какой момент создать эти атомарные бранчи и конвенция наименования, представленная выше, не единственная годная. Бранч можно создать непосредственно перед началом работы. А имена бранчей должны быть понятны всем участникам разработки. Имя должно быть как можно короче и при этом явно указывать на то, за какую часть функционала ветка отвечает.

Подходом, описанным выше, мы обеспечиваем безконфликтную работу нескольких разработчиков UI. У каждого фрагмента UI свой каталог в иерархии проекта. В каталоге фрагмента есть основной компонент, его набор стилей и свой набор дочерних компонентов. Также у каждого фрагмента может быть свой менеджер состояния (MobX, Redux, VueX сторы). Возможно, компоненты фрагмента используют какие-то глобальные стили. Однако изменять глобальные стили при разработке фрагмента новой страницы запрещено. Изменять дефолтное поведение и стиль общего атома дизайна также не стоит.

Примечание: под "атомом дизайна" подразумевается элемент из набора стандартных компонентов нашего сервиса — см. Atomic Design; в нашем случае предполагается, что система Атомарного Дизайна уже реализована.

Итак, мы физически отделили фронтовиков друг от друга. Теперь каждый из них может работать спокойно, не боясь конфликтов при мерже. Также каждый может в любой момент создать пулл реквест из своей ветки в feature/import-dev. Уже сейчас можно спокойно набрасывать статичесий контент и даже формировать интерактив в пределах одного хранилища состояния.

Но как нам обеспечить возможность взаимодействия фрагментов UI между собой?

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

Для создания этого сервиса нам понадобится еще одна ветка в git:

master --------------------------- >
  └ feature/import-dev ----------- >
    ├ feature/import-js-service -- >
    ├ feature/import-head -------- >
    ├ feature/import-filter ------ >
    ├ feature/import-table ------- >
    ├ feature/import-pager ------- >
    └ feature/import-footer ------ >

Примечание: не пугайтесь количества веток и не стесняйтесь плодить ветки. Git позволяет эффективно работать с большим количеством ветвлений. Когда вырабатывается привычка, ветвиться становится легко:

$/> git checkout -b feature/import-service
$/> git commit .
$/> git push origin HEAD
$/> git checkout feature/import-dev
$/> git merge feature/import-service

Кому-то это покажется напряжным, но профит минимизации конфликтов весомее. К тому же пока вы эксклюзивный владелец ветки, можете без опасений делать push -f без риска повредить чью-то локальную историю каммитов.

Фэйковые данные

Итак, на предыдущем этапе мы сделали заготовку интеграционного JS-сервиса (importService), сделали заготовки фрагментов UI. Но без данных наш прототип работать не будет. Ничего не рисуется кроме статических декораций.

Теперь нам надо определиться с примерной моделью данных и создать эти данные в виде JSON или JS файлов (выбор в пользу того или другого зависит от настройки импортов в вашем проекте; настроен ли json-loader). Наш importService, а также его тесты (о них будем думать попозже) импортируют из этих файлов данные, необходимые для имитации ответов от реального бэкенда (он пока еще не реализован). Куда положить эти данные не суть важно. Главное, чтобы их можно было легко импортировать в сам importService и тесты в нашем микросервисе.

Формат данных, конвенцию именования полей желательно обговорить с разработчиками бэка сразу. Можно, например, договориться об использовании формата, соответствующего спецификации OpenAPI Specification. Какой бы спецификации формата данных ни следовал бэк, фэйковые данные мы создаем в точном соответствии формату данных в бэке.

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

Контракты

Фэйковые данные могут служить хорошим заделом для начала работы над спецификацией будущего API в бэке. И тут неважно кто и насколько качественно реализует драфт модели. Решающее значение играет совместное обсуждение и согласование с участием разработчиков фронта и бэка.

Для описания контрактов (спецификации API) можно использовать специализированные инструменты. Напр., OpenAPI / Swagger. По-хорошему, при описании API с таким инструментом нет нужды в присутствии всех разработчиков. Этим может заниматься один разработчик (редактор спецификации). Результатом коллективного обсуждения нового API должны были стать некие артефакты вроде MFU (Meeting Follow Up), по которым редактор спецификации и конструирует справочник для будущего API.

По окончании создания драфта спецификации не должно потребоваться много времени, чтобы проверить корректность. Каждый участник коллективного обсуждения сможет независимо от других сделать беглый осмотр для проверки, что его мнение было учтено. Если что-то покажется некорректным, то можно будет уточнить через редактора спецификации (обычные рабочие коммуникации). Если все удовлетворены спецификацией, то ее можно опубликовать и использовать как документацию на сервис.

Юнит-Тестирование

Примечание: Лично для меня ценность юнит-тестов довольная низка. Тут я согласен с Дэвидом Хансоном (David Heinemeier Hansson @ RailsConf). "Юнит-тесты — это отличный способ убедиться, что ваша программа ожидаемым образом делает д… мо." Но я допускаю особые кейсы, когда юнит-тесты приносят много пользы.

Теперь, когда мы определились с фэйковыми данными, можно приступать к тестированию базового функционала. Для тестирования фронтовых компонентов можно использовать такие инструменты как karma, jest, mocha, chai, jasmine. Обычно рядом с тестируемым ресурсом JS кладется одноименный файл с постфиксом "spec" или "test":

importService
  ├ importService.js
  └ importService.test.js

Конкретное значение постфикса зависит от настроек сборщика пакетов JS в вашем проекте.

Конечно, в ситуации, когда бэк находится в "противозачаточном" состоянии, очень трудно покрыть юнит-тестами все возможные кейсы. Но и предназначение у юнит-тестов немного другое. Они призваны протестировать работу отдельных кусочков логики.

К примеру, хорошо покрывать юнит-тестами разного рода хэлперы (helper), через которые между JS компонентами и сервисами расшариваются куски логики или неких алгоритмов. Также этими тестами можно покрыть поведение в компонентах и сторах MobX, Redux, VueX в ответ на изменение данных пользователем.

Интеграционное и E2E-тестирование

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

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

E2E-тесты (End-to-End) работают на ещё более высоком уровне. Они проверяют, что поведение UI корректно. Например, проверка, что после отправки файла с данными в сервис, пользователю показывается крутилка, сигнализирующая о длящемся асинхронном процессе. Или проверка, что визуализация стандартных компонентов сервиса соответствует гайдам от дизайнеров.

Этот вид тестов работает при помощи некоторого фреймворка автоматизации UI. Например, это может быть Selenium. Такие тесты вместе с Selenium WebDriver запускаются в некотором браузере (обычно Chrome с "headless mode"). Работают они долго, но снижают нагрузку на специалистов QA, делая за них смоук тест.

Написание этих видов тестов довольно трудоемко. Чем раньше мы начнем их писать, тем лучше. Не смотря на то, что унас нет еще полноценного бэка, мы уже можем начинать описывать интеграционные тесты. У нас уже есть спецификация.

С описанием E2E тестов препятствий еще меньше. Мы уже набросали стандартные компоненты из библиотеки атомов дизайна. Реализовали специфичные куски UI. Сделали некоторый интерактив поверх фэйковых данных и API в importService. Ничто не мешает начать автоматизацию UI как минимум для базовых кейсов.

Написанием этих тестов можно опять же озадачить отдельных разработчиков, если имеются не озадаченные люди. И также для описания тестов можно завести отдельную ветку (как описано выше). В ветки для тестов нужно будет периодически мержить обновления из ветки "feature/import-dev".

Общая последовательность мержей будет такой:

1. Например, девелопер из ветки "feature/import-filter" создал ПР. Этот ПР проревьюили и мэйнтейнер ветки "feature/import-dev" вливает этот ПР.
2. Мэйнтейнер обявляет, что влито обновление.
3. Девелопер в ветке "feature/import-tests-e2e" затягивает крайние изменения мержем из "-dev ветки.

CI и автоматизация тестирования

Фронтовые тесты реализуются с помощью инструментов, работающих через CLI. В package.json прописываются команды для запуска разных видов тестов. Эти команды используются не только девелоперами в локальной среде. Они нужны еще и для запуска тестов в среде CI (Continuous Integration).

Если сейчас мы запустим билд в CI и ошибок не обнаружится, то в тестовую среду будет доставлен наш долгожданный прототип (80% функционала на фронте при не реализованном еще бэке). Мы сможем показать Василию приблизительное поведение будущего микросервиса. Васлилий попинает этот прототип и, возможно, сделает кое-какие замечания (возможно даже серьезные). На данном этапе вносить коррективы не дорого. В нашем случае бэк требует серьезных архитектурных изменений, поэтому работа по нему может идти медленнее, чем по фронту. Пока бэк не финализирован, внесение изменений в план его разработки не приведет к катастрофическим последствиям. При необходимости что-то поменять на этом этапе мы попросим внести коррективы в спецификацию API (в сваггере). После этого повторяются шаги, описанные выше. Фронтовики по-прежнему не зависят от бэкендеров. Отдельные специалисты фронтенда не зависят друг от друга.

Бэкенда. Контроллеры-заглушки

Отправной точкой разработки API в бэке является утвержденная спецификация API (OpenAPI / Swagger). При наличии спецификации работу в бэке также станет легче распараллеливать. Анализ спецификации должен навести разработчиков на мысль об основных элементах архитектуры. Какие общие компоненты / сервисы нужно создать, прежде чем приступать к реализации отдельных вызовов API. И тут опять же можно применить подход как с заготовками для UI.

Мы можем начать сверху, т.е. с наружнего слоя нашего бэка (с контроллеров). На этой стадии мы начинаем с роутинга, заготовок контроллеров и фэйковых данных. Слой сервисов (BL) и доступа к данным (DAL) мы пока не делаем. Просто переносим данные из JS в бэкенд и программируем контроллеры так, чтобы они реализовывали ожидаемые ответы для базовых кейсов, выдавая куски из фэйковых данных.

По завершению этой стадии фронтовики должны получить работающий бэкенд на статичных тестовых данных. Причем именно тех данных, на которых фронтовики пишут интеграционные тесты. По идее, в этот момент не должно составить большого труда переключить JS шлюз (importService) на использование заготовок контроллеров в бэке.

Ответная часть для запросов через Websocket концептуально не отличается от Web API контроллеров. Эту "ответку" также делаем на тестовых данных и подключаем importService к этой заготовке.

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

Бэкенд. Финализация контроллеров. Заглушки в DAO

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

Примечание: мы по-прежнему не зависим от того, реализована ли схема данных в БД.

Бэкенд. Финализация DAO. Реальная БД

После того, как схема данных реализована в БД, мы можем перенести в нее тестовые данные из предыдущих этапов и переключить наш зачаточный DAL на работу с реальным сервером БД. Т.к. мы в БД переносим изначальные данные, создававшиеся для фронта, все тесты должны остаться актуальными. Если какой-то из тестов упадет, значит что-то пошло не так и нужно разбираться.

Примечание: вообще с очень большой вероятностью работы со схемой данных в БД для новой фичи будет немного; возможно изменения в БД будут сделаны одновременно с реализацией сервисов в BL.

По окончанию этой стадии мы получаем полноценный микросервис, альфа-версию. Эту версию уже можно показать внутренним пользователям (Product Owner'у, продуктологу или еще кому-то) для оценки как MVP.

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

Заключение

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

Профит этого подхода появляется тогда, когда мы в самом начале быстро реализуем заготовки, максимально приближенные к будущей реальной реализации и физически разделяем работы над разными частями на уровне структуры файлов в проекте и на уровне системы управления кодом (git).

Надеюсь, что вы нашли данную статью полезной.

Спасибо за внимание!

Let's block ads! (Why?)

[Из песочницы] Преобразование черно-белых изображений в ASCII-графику при помощи неотрицательного матричного разложения

[Перевод] Как мощные землетрясения Боливии открыли горы на глубине 660 километров под землей

Все школьники знают, что планета Земля разделена на три (или четыре) больших слоя: кора, мантия и ядро. В целом это верно, хотя это обобщение не берет в расчет несколько дополнительных слоев, определенных учеными, один из которых, например, переходный слой внутри мантии.

В исследовании, опубликованном 15 февраля 2019 года, геофизик Джессика Ирвинг и студент-магистрант Венбо Ву из Принстонского университета, в сотрудничестве с Сидао Ни из Геодезического и Геофизического Института в Китае, использовали данные, полученные во время мощного землетрясения 1994 года в Боливии для нахождения гор и других топографических элементов на поверхности переходной зоны глубоко внутри мантии. Этот слой, находящийся на глубине 660 километров под землей, разделяет верхнюю и нижнюю часть мантии (не имея формального названия для этого слоя, исследователи назвали его просто «660–километровая граница»).

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

Большие землетрясения намного мощнее обычных – энергия которых увеличивается 30–кратно при каждом дополнительном шаге вверх по шкале Рихтера. Ирвинг получает свои лучшие данные с землетрясений с магнитудами 7.0 и выше, потому что сейсмические волны, посылаемые настолько мощными землетрясениями, расходятся в разные стороны и могут пройти через ядро на другую сторону планеты и обратно. Для этого исследования ключевые данные были получены с сейсмических волн, которые были зарегистрированы с землетрясения с магнитудой 8.3 – второе самое глубокое землетрясение, когда-либо зарегистрированное геологами, – которое потрясло Боливию в 1994 году.

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

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

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

«Мы знаем, что почти все объекты имеют неровную поверхность и поэтому могут рассеивать свет», – сказал Венбо Ву, главный автор этого исследования, который недавно получил степень доктора в геономии и сейчас проходит постдокторантуру в Калифорнийском Технологическом Институте. «Благодаря этому факту мы можем «видеть» эти объекты – рассеивающие волны несут информацию о грубости поверхностей, которые встречаются им на пути. В этом исследовании мы изучали рассеивающие сейсмические волны, распространяющиеся глубоко внутри Земли, чтобы определить «грубость» найденной 660–километровой границы».

Исследователи были удивлены, насколько «груба» эта граница – даже более, чем поверхностный слой, на котором мы живем. «Другими словами, этот подземный слой имеет топографию сложнее, чем Скалистые Горы или горная система Аппалачи», – уточнил Ву. Их статистическая модель не смогла определить точные высоты этих подземных гор, но существует большая вероятность того, что они намного выше, чем что-либо на поверхности Земли. Также ученые заметили, что 660-километровая граница тоже неравномерно распределена. Таким же образом, как и наземный слой имеет гладкую поверхность океана в одних частях и массивные горы в других, 660–километровая граница также имеет грубые зоны и гладкие пласты на своей поверхности. Исследователи также изучили подземные слои на глубине 410 километров и на вершине среднего слоя мантии, однако не смогли найти похожую грубость этих поверхностей.

«Они обнаружили, что 660–километровая граница также сложна, как и поверхностный земной слой», – сказала сейсмолог Кристина Хаузер, доцент Токийского Технологического Института, которая не участвовала в этом исследовании. «Использовать сейсмические волны созданные мощными землетрясениями, чтобы найти 3 километровую разницу в высоте рельефа находящегося 660 километров глубоко под землей — это невообразимый подвиг.… Их открытия означают, что в будущем, используя более сложные сейсмические инструменты, мы сможем обнаруживать ранее неизведанные, малозаметные сигналы, которые раскроют нам новые свойства внутренних слоев нашей планеты».

Сейсмолог Джессика Ирвинг, доцент геофизики, держит два метеорита из коллекции Принстонского Университета, содержащие железо и предположительно являющиеся частью планетоземалей.
Фото сделано Денис Аппелуайтом.

Что это означает?

Существование грубых поверхностей на 660–километровой границе имеет важное значение для понимания как формируется и функционирует наша планета. Этот слой разделяет мантию, составляющую около 84 процентов объема нашей планеты, на верхние и нижние секции. Годами геологи спорили о том, насколько важна эта граница. В частности, они изучали, как тепло транспортируется сквозь мантию – и перемещаются ли нагретые породы с границы Гутенберга (слой, разделяющий мантию от ядра на глубине 2900 километров) вверх до вершины мантии или это перемещение прерывается на 660–километровой границе. Некоторые геохимические и минералогические данные предполагают, что верхние и нижние слои мантии имеют разные химические составы, что поддерживает идею о том, что оба слоя не смешиваются термально или физически. Другие наблюдения предполагают, что верхние и нижние слои мантии не имеют никакой химической разницы, что порождает спор о так называемой «полностью–перемешанной мантии» («well-mixed mantle»), где оба слоя мантии участвуют в смежном цикле теплообмена.

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

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

Что могло бы послужить причиной настолько значительной химической гетерогенности? Например, появление каменных пород в слоях мантии, которые принадлежали земной коре и переместились туда в течении многих миллионов лет. Ученые долго спорили о судьбе плит на морском дне, которые проталкиваются внутрь мантии в зонах субдукции, коллизии которых происходят вокруг Тихого Океана и в других частях земного шара. Вейбо Ву и Джессика Ирвинг предполагают, что остатки этих плит могут сейчас быть сверху или снизу 660–километровой границы.

«Многие считают, что это довольно сложно изучать внутреннюю структуру планеты и ее изменения за последние 4.5 миллиардов лет, только используя данные сейсмических волн. Но это далеко не так!, – сказала Ирвинг – это исследование дало нам новую информацию о судьбе древних тектонических плит, которые спускались внутрь мантии в течении многих миллиардов лет».

В конце Ирвинг добавила: «Я считаю что, сейсмология наиболее интересна, когда она помогает нам понять внутреннее строение нашей планеты в пространстве и времени».

От автора перевода: всегда хотел попробовать себя в переводе научнопопулярной статьи с ангийского на русский, но не ожидал насколько это сложно. Большое уважение тем, кто регулярно и качественно переводит статьи на Хабре. Что бы профессионально перевести текст, надо не только знать английский, но также понять саму тему изучая сторонние источники. Добавлять немного «отсебятины» что бы звучало более натурально, но и не перебарщавать, что бы не испортить статью. Большое спасибо за чтение :)

Let's block ads! (Why?)

[Из песочницы] Визуализация зависимостей и наследований между моделями машинного обучения

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

Первая мысль которая пришла в голову это то что, если я буду знать и пойму больше моделей, мои качества как исследователя и инженера в целом, возрастут. Эта идея подтолкнула меня к изучению статей с последних конференций по машинному обучению. Структурировать такую информацию довольно сложно, и необходимо записывать зависимости и связи между методами. Я не хотел представлять зависимости в виде таблицы или списка, а хотелось что-то более естественное. В итоге, я понял что иметь для себя трехмерный граф с ребрами между моделями и их компонентами, выглядит довольно интересно.

Например, архитектурно GAN [1] состоит из генератора (GEN) и дискриминатора (DIS), Состязательный Автокодировщик (AAE) [2] состоит из Автокодировщика (AE) [3] и DIS,. Каждый компонент является отдельной вершиной в данном графе, поэтому для AAE у нас будет ребро с AE и DIS.

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

Естественно, я проводил исследования и пытался найти аналоги тому, что я делал. Существует достаточно сервисов, которые позволяют следить за появлением новых статей в данной области. Но все эти методы направлены в первую очередь на упрощение приобретения знаний, а не на помощь в создании новых идей. Креативность важнее опыта, и инструменты, которые могут помочь мыслить в различных направлениях, и видеть более цельную картину, как мне кажется должны стать неотъемлемой частью процесса исследования.

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

Всего за несколько месяцев я разобрал около 250 статей с последней конференции NeurIPS и около 250 других статей, на которых они основаны. Большинство областей были мне совершенно незнакомы, чтобы понять их потребовалось несколько дней. Иногда я просто не мог найти правильного описание для моделей, и того, из каких компонент они состоят. Исходя из этого, вторым логическим шагом было создание возможности авторам самим добавлять и изменять методы в графе, ведь никто, кроме авторов статьи, не знает, как наилучшим образом разобрать и описать свой метод.

Пример того что получилось по итогу представлен по ссылке.

Я надеюсь, что этот проект будет кому-нибудь полезен, хотя бы потому что он, возможно, позволит кому-то получить ассоциации, которые могут навести на новую интересную идею. Я был удивлен когда услышал как на чем основывается идея генеративных состязательных сетей. На MIT machine Intelligence podcast[4], Yan Goodfellow рассказал что идея состязательных сетей ассоциирована с «позитивной» и «негативной» фазой обучения Boltzman Machine[5].

Этот проект community-driven. Мне бы хотелось развивать его и мотивировать больше людей добавлять туда информацию о своих методах, или редактировать уже внесенную. Я верю что более точная информация о методах и лучшие технологии визуализации действительно помогут сделать это полезным инструментом.

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

Некоторые технические подробности можно почитать по ссылке.

[1] Ian J.Goodfellow, Jean Pouget-Abadie, Mehdi Mirza, Bing Xu, David Warde-Farley, Sherjil Ozair, Aaron Courville, Yoshua Bengio. Generative Adversarial Nets.

[2] Alireza Makhzani, Jonathon Shlens, Navdeep Jaitly, Ian Goodfellow, Brendan Frey. Adversarial Autoencoders.

[3] Dana H. Ballard. Autoencoder.

[4] Ian J.Goodfellow: Artificial Intelligence podcast at MIT.

[5] Ruslan Salakhutdinov, Geoffrey Hinton. Deep Boltzmann Machines

Let's block ads! (Why?)

[Из песочницы] Необходимые материалы для старта разработки обучающего VR проекта

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

Для общего понимания разберем 3-варианта передачи информации заказчиком, компании исполнителя, для реализации VR проекта.

Вариант 1

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

Пример: Процесс обслуживания и замены платы оборудования.

Описан следующий алгоритм действий:

• Протереть щиток;
• Открутить болты;
• Убрать щиток;
• Отсоединить коммутатор;
• Заменить коммутатор;
• Проверить коммутатор.

Вариант 2

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

После чего команда разработчиков запрашиваем следующие материалы:

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

Вариант 3

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

Мы со своей стороны проводим анализ:

• На сколько дорогостоящее оборудование;
• На сколько сложен процесс починки;
• Сколько времени потребуется на процесс реализации всего материала в VR.
• И по окончанию изучения всего материала предлагаем свои варианты решения задачи.

Как мы можем видеть существует три варианта развития событий:

Первый — заказчик подготавливает полный пакет информации от и до;
Второй — заказчик понимает чего хочет;
Третий — заказчику нужна помощь.

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

Заказчик предоставляет следующие материалы:

• Методические указания в текстовом или графическом виде;
• Изображения, которые будут давать представление 3D моделей объектов, локаций и персонажей для VR проекта;
• Видео материалы;
• Аудио файлы, для озвучки и мн.др.

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

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

• Отвертка парит в воздухе и самостоятельно откручивает болты;
• Извлекается коммутатор;
• Устанавливается новый коммутатор;
• Проходит проверка системы питания.
• Во время этого процесса высвечивается сопроводительный текст, рядом с предметами, а также происходить подсветка (отвертки, болтов, проводов и других составляющих).

Сопроводительный текст — последовательность действий:

• Протереть щиток;
• Открыть щиток;
• Поменять коммутатор;
• Проверить работоспособность системы питания.
• На данном этапе пользователю требуется наблюдать за всем происходящим и запоминать последовательность действий.

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

Картина, которую видит пользователь:

• Пыльное оборудование;
• Средства для очистки;
• Отвертка;
• Новый коммутатор;
• Оборудование для проверки работоспособности.

Инструкция:

• Протереть щиток;
• Открутить болты;
• Убрать щиток;
• Отсоединить коммутатор;
• Заменить коммутатор;
• Проверить работоспособность системы питания.

Протереть оборудование и снять щиток не составит труда, а вот заменить коммутатор — это уже сложнее. Когда пользователь доходит до пункта “Замена коммутатора”, ему начинают высвечиваться следующие подсказки:

• Отсоедините питание;
• Открутите крепеж;
• Аккуратно параллельно полу достаньте коммутатор;
• Установите новый;
• Повторите все действия в обратном порядке и тд.

После того, как пользователь проходит все задания с применением подсказок, программа переводит его в режим экзаменационного формата.

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

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

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

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

В Заключении хотелось бы сказать: “Прежде чем наша студия поможет обучить ваших сотрудников, нам придется погрузиться в вашу работу и научиться всему самим”.

Let's block ads! (Why?)

Слуховой аппарат на базе open source — как он устроен

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

^{Фото kyle smith / Unsplash}

Почему появился Tympan

По данным ВОЗ, более 5% населения планеты — это 466 миллионов человек — страдает от инвалидизирующей потери слуха. Она подразумевает, что разница в громкости звуков, которые воспринимает левое и правое ухо, составляет 40 дБ у взрослых и 30 дБ у детей. Для сравнения: уровню громкости в 30 дБ соответствует тиканье часов.

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

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

Среди авторов проекта числится Джоэл Мерфи (Joel Murphy), который участвовал в создании open source пульсометра Pulse Sensor и открытого нейрокомпьютерного интерфейса OpenBCI. Другая знаковая фигура — Эдди Вагенкнехт (Addie Wagenknecht), она долгое время выступала председателем конференции Open Hardware Summit в MIT.

Как он устроен

Аппаратная часть. В качестве базовой платы выбрана Teensy 3.6. Она имеет встроенный USB-порт и поддерживает SD-карты. Запрограммировать её можно с помощью Arduino IDE. Для работы со звуком используется микросхема TI TLV320AIC3206. Она выполняет функции ЦАП и АЦП, а также усилителя. Плата имеет встроенные микрофоны, разъемы для внешних микрофонов и наушников, Bluetooth-интерфейс и аккумулятор.

Программное обеспечение. Код «упакован» в библиотеку Arduino. Для работы со звуком в ней представлены фильтры с конечной и бесконечной импульсной характеристикой, детекторы уровня сигнала, а также функции быстрого и обратного преобразования Фурье.

Большую часть компонентов устройства Tympan (например, микрофоны) пользователи могут менять на свое усмотрение. Однако аудиокодеки и процессор заменить не получится.

На GitHub разработчики также приводят акустические параметры устройства. Например, максимальное значение выходного сигнала составляет 121 дБ, а уровень шума на входе системы — 39 дБА.

Что думают люди

Устройство Tympan уже приобрел один инженер из Нью-Йорка. По его словам, первые тесты прошли удачно — в предоставленной документации была освещена большая часть вопросов, а сами разработчики оперативно давали комментарии. В будущем пользователь планирует отдать слуховой аппарат своей слабослышащей матери. Пользу проекта отметили и резиденты Hacker News. Они считают, что в перспективе Tympan способен решить проблемы со слухом у многих людей.

^{Фото JD Mason / Unsplash}

Хотя большая часть отзывов была положительной, были и те, кто высказал ряд сомнений. Например, есть мнение, что рабочие параметры «открытого» слухового аппарата будут хуже, чем у более дорогих проприетарных гаджетов. Резидент HN рассказал, что разработка подобных устройств требует глубоких познаний в обработке сигналов и шумоподавлении. Проведение серьезных R&D в этих областях требует существенный объем ресурсов, которых у разработчиков open source проектов может и не быть.

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

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

Другие проекты

Разработками в этой сфере занимаются и крупные компании. Например, год назад Google совместно с GN Hearing, проектирующей аудиотехнологии для слабослышащих людей, начали проектировать протокол, который позволит подключать слуховые аппараты напрямую к Android-смартфонам. Его назвали ASHA (Audio Streaming for Hearing Aids), и он использует технологию Bluetooth Low Energy на основе Bluetooth 5.0, чтобы продлить время жизни устройств.

Помимо слуховых аппаратов, в open source появляются и другие мед. гаджеты. Например, тот же Джоэл Мерфи участвует в разработке фитнес-браслета OpenHAK. Его цель — дать пользователям устройств больше контроля за своими данными. Также разработчики хотят расширить пул функций, которые выполняют фитнес-браслеты. Первые приложения для OpenHAK уже выложены на GitHub.

---

Дополнительное чтение — из нашего «Мира Hi-Fi»:

Как написать музыку, используя ООП
«Несмотря на возраст»: как беречь слух
Разработан метод шумоизоляции, гасящий до 94% шумов — как он работает
«Гул Земли»: теории заговора и возможные объяснения
Энтузиаст воссоздал звуковую карту Sound Blaster 1.0 — рассказываем о проекте

---

Let's block ads! (Why?)

История с продолжением: собственный компилятор Паскаля для Windows с чистого листа

Неожиданно тёплый приём, оказанный публикой Хабра моему посту о самодельном компиляторе XD Pascal для MS-DOS, заставил меня задуматься. Не досадно ли, что любительский проект, которому я отдал немало сил, лежит у меня мёртвым грузом с тех самых пор, как из Windows полностью исчезла виртуальная машина DOS? Итогом размышлений стал компилятор XD Pascal для Windows. Возможно, он лишился некоторой доли ностальгического шарма и утратил возможность наивной работы с графикой через прерывания BIOS. Однако переход на Windows вдохнул новую жизнь в проект и открыл дорогу к давней мечте — самокомпиляции.

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

Пять шагов к самокомпиляции в Windows

Стоит сказать несколько слов об основных задачах, которые пришлось решить на пути от DOS к Windows:

Формирование заголовков и секций исполняемого файла. Помимо официального описания формата Portable Executable, отличным подспорьем на этом этапе стала статья Creating the smallest possible PE executable. Поскольку в заголовках и секциях требуются точные адреса процедур и переменных, а их можно узнать лишь после вычисления размера кода и глобальных данных, то компиляцию пришлось сделать трёхпроходной. При первом проходе строится граф вызовов процедур и отмечаются «мёртвые» процедуры; при втором — вычисляются адреса, размер кода и данных, заполняются заголовки; при третьем — генерируется код. Такой кунштюк весьма неизящен, особенно с учётом того, что при каждом проходе заново повторяются все этапы компиляции, начиная с лексического разбора. Однако он приводит к очень лаконичному исходному коду компилятора и не требует никакого промежуточного представления программы.

Новый генератор кода. Компиляция для Windows потребовала заменить пары регистров «сегмент — смещение» на 32-битные регистры смещений, а также удалить (а местами добавить) префиксы изменения длины операнда (66h) и длины адреса (67h).

Директива для объявления внешних функций Windows API. Все имена функций, объявленных с директивой external, заносятся в таблицы секции импорта исполняемого файла. Поскольку эти функции требуют передачи аргументов справа налево, пришлось вручную инвертировать порядок аргументов в объявлении и вызовах всех таких функций. Тем самым отпала необходимость в инверсии средствами компилятора. Ради простоты все аргументы процедур и функций в XD Pascal передаются в виде 32-битных величин; к счастью, это правило справедливо и для функций Windows API, так что взаимодействие с системными библиотеками не привело к усложнению механизма передачи аргументов.

Удаление множеств и инфиксных строковых операций из исходного кода. Это требование связано с задачей самокомпиляции. Вычисление любых выражений в XD Pascal строится так, что все промежуточные результаты имеют длину 32 бита и сохраняются в стеке. Для строк и множеств Паскаля этот подход неприемлем. Точнее, он позволил бы иметь множества размером до 32 элементов, но такие множества оказались бы практически бесполезны.

Обёртки для некоторых процедур. Идея самокомпиляции привела к обёртыванию вызовов некоторых процедур стандартной библиотеки. Сигнатура обёртки едина для случаев компиляции внешним компилятором (Delphi/Free Pascal) и самокомпиляции; обёртываемые процедуры при этом различаются. Таким образом, вся специфика способа компиляции локализуется внутри нескольких обёрток. Паскаль пестрит процедурами, которые при ближайшем рассмотрении оказывается невозможно реализовать по правилам самого Паскаля: Read, Write, Move и т.д. Для самых употребительных процедур, в том числе Read и Write, я сделал исключение и реализовал их нетипичными для грамматики языка, но привычными любому знатоку Паскаля. Для большинства остальных нетипичных процедур понадобились обёртки. Таким образом, XD Pascal не во всём совместим с Delphi или Free Pascal, однако большой беды в этом нет, поскольку даже сам Free Pascal в режиме совместимости с Delphi фактически остаётся несовместимым.

Компиляция программ с GUI

Задача самокомпиляции, несмотря на своё символическое значение, остаётся ограниченной: компилятор является консольной программой и поэтому выглядит не совсем полноправным обитателем мира Windows. Понадобилось ещё несколько нововведений на пути к компиляции программ с оконным интерфейсом:

Директива компилятору для установки типа интерфейса. Тип интерфейса (консольный или графический) должен быть указан в отдельном поле заголовка исполняемого файла. Как известно, в Delphi и Free Pascal для этого существует директива $APPTYPE. Аналогичная директива $A появилась и в XD Pascal.

Операция взятия адреса процедур и функций. В классическом Паскале нет полноценных указателей на процедуры и функции — их в некоторой мере заменяет процедурный тип. Этот тип в XD Pascal не реализован. Как бы то ни было, до сих пор применение операции @ к процедурам в моём скромном проекте казалось мне бесполезным. Однако обработка событий Windows API построена на обратных вызовах (callbacks), и здесь передача адреса вызываемой процедуры-обработчика вдруг стала насущной необходимостью.

Явное указание имён подключаемых библиотек. Для консольных программ было достаточно импорта функций Windows API из библиотеки KERNEL32.DLL. Программы с GUI потянули за собой USER32.DLL, GDI32.DLL и т.д. Понадобилось расширить синтаксис директивы external, добавив туда имя библиотеки.

Демонстрационная программа с GUI

Что в итоге

В результате получился очень простой самокомпилируемый компилятор для Windows. Вряд ли корректно сравнивать его с могучими коллективными проектами типа Free Pascal. Скорее он попадает в весовую категорию известного любительского BeRo Tiny Pascal. По сравнению с ним XD Pascal имеет заметные преимущества: более строго соблюдается грамматика Паскаля и контролируются ошибки, есть полноценный файловый ввод/вывод, поддерживается арифметика чисел с плавающей точкой, нет зависимости от внешнего ассемблера, допускается компиляция программ с оконным интерфейсом.

Далее мне предстоит разобраться с ложноположительным срабатыванием некоторых антивирусов — новой проблемой, о которой я и не задумывался в маленьком уютном мирке MS-DOS. Если повезёт, XD Pascal будет внедрён, наряду с BeRo Tiny Pascal, в лабораторный практикум по курсу конструирования компиляторов в МГТУ им. Н.Э. Баумана.

Let's block ads! (Why?)

О безопасности, номерах, электронных почтах и, совсем немного о рекламе

Warning!

Дабы заранее предупредить различные вопросы, а также обеспечить удобство чтения, далее — небольшой дисклеймер: всё, что будет написано далее — основано на личном и субъективном опыте, выражает личное мнение автора и ни в коем случае не является призывом к каким либо противоправным или антигосударственным действиям, статья написана сухим языком и без картинок сгоряча, не является информативной или правдой.

Что-то вроде исторической справки

Наверняка все помнят, как раньше работал интернет для большинства людей: приезжает дядя, проводит кабель, вы на рабочем столе жмёте иконку Internet explorer'a и вуаля, вы — пользователь интернета. Вы могли искать информацию поиском, создавать электронную почту по одному, не факт что реальному ФИО, регистрироваться в блогах и социальных сетях по почте, покупать что-то в интернет магазинах всё так же по ФИО и почте.

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

Так мы пришли в 2019.

Реальность

А реальность грустна и тревожна: как часто вы при регистрации сталкивались с просьбой указать свой номер? Уверен, за последние 3 года это происходило если не каждый, то в 9 из 10 раз. Более того, редкий из старых сервисов не спросит номер при повторном логине, если вы не заходили года два три.

Как же так вышло? Всё просто: ваш мобильный номер, оформленный на вас официально — лучший способ вас идентифицировать, привлечь ваше внимание, потревожить вас.

По вашему номеру вас может найти кто угодно, от сотрудника центра «Э» до мошенника, чему было много свидетельств и на этом портале в том числе.

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

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

Пользователям

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

Посмотрим на примере меня, сколько можно ТОЛЬКО по открытым источникам узнать о вас информации:

1. Гуглим никнейм: узнаём, что как минимум я являюсь пользователем Пикабу, когда-то давно играл в браузерки, но сейчас владею аккаунтом на Steam, интересуюсь дизайном, кастомными прошивками для xperia z1 и кардингом.
2. К сожалению не находим ничего полезного по почте, кроме никнейма, который уже просмотрели выше.
3. Тем же макаром не находим ничего по номеру. Можно расслабиться? Как бы не так: набираем в плей маркете «определение номера», скачиваем первое попавшееся приложение и внезапно видим, что сразу позволяет узнать как минимум ФИ, как максимум, что я стильно одеваюсь, ходил на какие-то курсы, работал курьером, предположительно разбираюсь в маркетинге и учусь в Международном Университете в Москве на факультете Управления Крупными Городами.

Дальше больше: используя никнейм и сервис поиска по номеру, находим ВКонтакте, где получаем косвенные подтверждения тезисам, высказанным выше по подпискам и информации профиля, и получаем возможность ознакомиться с списком друзей.

Вы спросите: «И что? Эта информация бесполезна!»

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

Что тут такого? Шантажистов ты просто пошлёшь, а реклама — на то и реклама, чтобы её не смотреть.

Снова представим себя в роли недобросовестного полицейского, мошенника и etc:
На самом деле всё что было написано выше для нас — детский лепет, белая вершина чёрной пирамиды. Не буду писать о том, как получить доступ к «чёрной» части данных, все цены уже были описаны здесь же: 1;2;3.

Лучше подумаем, что с этим можно сделать.

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

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

Что же делать?

Мои, хотя почему мои, базовые, рекомендации таковы:

1. Держите минимум две сим-карты: На одну регистрируйтесь на разных сайтах в интернете, банках, букмекерских конторах и что угодно ещё, но ни в коем случае не публикуйте этот номер в открытом доступе и не говорите никому включая друзей, родственников, etc. Соответственно другую используйте публично, для связи с друзьями. От товарища майора это не защитит, но мошенникам создаст дополнительные препятствия, или хотя бы удорожит их деятельность на ещё пару-тройку тысяч рублей.
2. То же, что и 1, только с электронными почтами.
3. Используйте сервисы, предоставляющие временный номер и временную почту для регистраций, ссылку давать не буду т.к. таковые легко гуглятся.
4. Не публикуйте в интернете важную конфиденциальную информацию нигде, будь то блог в ЖЖ или личные сообщения ВКонтакте.
5. По возможности не указывайте свои реальные данные нигде.
6. Не пользуйтесь услугой доставки до дома, или вызывайте курьера на какой-нибудь ближайший адрес (пример — соседний дом, если речь о городе, крупная улица, если о пгт или того хуже)
7. Не пользуйтесь интернетом.
8. Уходите в тайгу, а нет, она же сгорела.

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

Итак, как же обеспечить безопасность пользователей и сохранить репутацию? Мои варианты ниже:

1) Регистрация без почты и телефона.

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

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

2) Регистрация только по номеру.

Удивительно, но вариант гораздо более удобный чем регистрация по почте, которая в 2019м автоматически воспринимается, как «мы будем спамить вам бесполезную рассылку all day every day», и по сути таковым и является.

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

3) Регистрация только по почте.

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

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

Ну и немного про рекламу, в заголовке ведь было обещано

2019 — это когда ты удаляешь письма не читая, 2019 — это когда ты услышав звонок думаешь «снова эти бесплатные юридические консультации/фильтры воды всего за 100 т. р./опросы/что угодно ещё). 2019 — это год, когда вам и вашему сервису необходимо сократить контакт с клиентом по электронной почте и мобильному номеру до минимума. Наладьте чат на сайте или в приложении в личном кабинете. Это не трудно, не дорого, но это бесценно, когда речь заходит о лояльности.

А если вы не согласны, ответьте на простой вопрос — ответите ли вы на звонок, если увидите, что гугл звонилка, гетконтакт или что-то подобное отметит его как спам, и если да — то с каким настроем.

Из историй из жизни: лето, 10 утра, я на кровати, сплю. ЗВОНОК. Гугл определяет как рег.ру.
Просыпаюсь, в голове мысли, что мне сайт эшники прикрывают? Отвечаю на звонок:

-> Добрый день, это рег.ру, у вас возникали проблемы при использовании нашего сервиса?
-> Нет, сервис удобный, интерфейс понятный.
-> Спасибо, до свидания.

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

Upd: Огромное спасибо пользователю berez, за исправление моих школьных ошибок с запятыми и тся/ться.

Let's block ads! (Why?)

Face ID на iPhone можно обмануть очками и изолентой (не синей)

На конференции Black Hat 2019 в Лас-Вегасе (штат Невада, США) эксперты по безопасности продемонстрировали, как можно достаточно просто обойти систему разблокировки «по лицу» Face ID, применяющуюся в смартфонах Apple, используя своеобразную биометрическую «ахиллесову пяту».
Оказалось, что обхитрить датчики Face ID несложно: для этого нужно лишь надеть обычные очки, поверх линз которых наклеены большие квадратики из черной изоленты, внутри который наклеены маленькие квадратики из белой изоленты.

«Ахиллесова пята» была найдена в особенностях работы Face ID, пишет издание ThreatPost.

Как выяснили эксперты, функция распознавания внимания Attention Detection не сканирует область глаз, когда пользователь находится перед смартфоном в очках.

Способ обхода Face ID приведен на этом слайде:

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

Таким способом, система биометрической аутентификации Apple вводится в заблуждение.

Ведь для этой системы создается впечатление, что пользователь устройства находится в сознании и смотрит прямо в камеру.

Конечно, в реальной ситуации выполнить подобную атаку довольно проблематично, что было признано исследователями на конференции Black Hat 2019, так как для использования этой уязвимости нужно, чтобы был выполнен ряд таких условий:

• наличие под рукой очков (они должны быть не солнцезащитными), изоленты двух цветов и ножниц;
• должен быть физический доступ к смартфону;
• спящий или обездвиженный пользователь, который не заметит, что на него одели очки.

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

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

Let's block ads! (Why?)