Исследователи из компании Armis обнаружили восемь критичных уязвимостей в реализациях Bluetooth. Уязвимости получили следующие CVE: CVE-2017-0781, CVE-2017-0782, CVE-2017-0783, CVE-2017-0785 (Android); CVE-2017-1000251, СVE-2017-1000250 (Linux); CVE-2017-8628 (Windows). Устройства на iOS пока не получили CVE-идентификатора. Все уязвимости объединены под общим названием: BlueBorne.

Вектор атаки BlueBorne может потенциально повлиять на все устройства с возможностями Bluetooth, которых чем 8,2 миллиарда. Bluetooth является ведущим и наиболее распространенным протоколом для ближней связи и используется всеми устройствами — от обычных компьютеров и мобильных устройств до устройств IoT, таких как телевизоры, часы, автомобили и медицинские приборы.

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

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

Техническое описание атаки доступно здесь.

Видео демонстрации атаки Windows:

Видео демонстрации атаки Linux:

Видео демонстрации атаки Android:

Original source: habrahabr.ru (comments, light).

Привет всем хабра-читателям!

Практически одновременно с развязкой третьего сезона сериала Twin Peaks мы выпустили очередной релиз операционной системы ReactOS с номером 0.4.6. Релиз доступен для загрузки прямо сейчас, и совсем не нужно ждать октября или ноября, как в случае с iPhone X.



Скачать | Прочитать официальную новость | Посмотреть список изменений | TL;DR | Тесты

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



Так же стоит отметить, что в релизе присуствует первоначальная реализация движка Shim (Microsoft Windows Application Compatibility Infrastructure), применяемого в Windows для обеспечения совместимости с приложениями, собранными для старых версий ОС. По умолчанию Shim пока отключен и требует явной активации в реестре.

По сравнению с прошлым выпуском добавлено более миллиона новых unit-тестов, оценивающих соответствие с поведением Windows. Общие число unit-тестов преодолело отметку в 14 миллионов, из которых завершаются ошибкой 18419 (0.129%)

Всего закрыто 186 отчётов об ошибках, из которых самая старая проблема (CORE-4107, невозможность зарегистрировать Firefox как браузер по умолчанию) оставалась неисправленной 8 лет.

Судьба USB

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

Мы с нетерпением ждем ваших впечатлений, пожеланий и баг-репортов, и уже наполную работаем над подготовкой релиза 0.4.7. Пишите свои комментарии!

И помните: ReactOS совсем не то, чем кажется!

Original source: habrahabr.ru (comments, light).

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

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

Тест на проникновение

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

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

Сканирование на наличие уязвимостей

Представьте, что вы решили взломать сайт «голыми руками». Что вы сделаете? В первую очередь, постараетесь определить версию используемого Web-сервера и/или CMS-системы. Зачем? Для того, чтобы «прогуглить» и найти информацию об уже известных уязвимостях и имеющихся эксплойтах. Так злоумышленники поступали 15 лет назад, так же поступают и сейчас.

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

Сканирование уязвимостей позволяет быстро «перелопатить» ИТ-инфраструктуру и найти проблемные места. Но сканер действует линейно и может пропустить интересные комбинации уязвимостей, которые в совокупности создают серьезную брешь в защите.

Рассмотрим следующий пример. Крупная производственная компания заказала тестирование защищенности. В первый день внутреннего тестирования на ресепшн замечаем на стикере пароль учетной записи, записанный заботливой рукой секретаря. Мы его скрыто фотографируем и через пять минут с данной учеткой запускаем специальную утилиту для поиска «расшаренных» папок (сейчас такой сканер есть в составе того же Metasploit Framework). В результате находим рабочую станцию сотрудника технической поддержки, ответственного за «накатывание» образов ОС на машины новых сотрудников компании.

Для своего и нашего удобства ИТ-специалист «расшарил» для всех папку с подготовленными образами. Мы не преминули воспользоваться такой любезностью и «вытянули» хеш пароля локального администратора, который и «раскрутили» за ночь. Полный доступ ко всем рабочим станциям предприятия был получен за одни сутки! Применение обычного сканера позволило бы найти «расшаренную» папку, но сканер не смог бы ни заглянуть внутрь, ни раскрутить хеш.

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

Анализ конфигурации

Любой компонент ИТ-инфраструктуры (ОС, СУБД, активное сетевое оборудование и т.п.) содержит массу настроек, которые и определяют уровень защищенности. Правильные настройки можно найти в документации вендора или в статьях экспертов, делящихся своим опытом. На основе подобных материалов такие организации, как National Institute of Standards and Technology и Center of Internet Security уже многие годы готовят чеклисты, позволяющие проводить аудит конфигурации различных систем. Существуют аналогичные закрытые проекты и в рамках сообществ ИТ-аудиторов компаний «Большой четверки» (BIG4).

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

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

Цели тестирования защищенности

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

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

Комплексное тестирование защищенности

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

Процесс тестирования защищенности разобьем на следующие этапы в соответствии с этапами реального взлома:

1. поиск целей;
2. поиск уязвимостей;
3. эксплуатация;
4. расширение привилегий и зоны влияния.

Шаг 1. Поиск целей

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

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

На данном шаге мы изучаем:

• сайты, связанные с компанией заказчика, а именно: узнаем доменные имена, адреса электронной почты, структуру организации и т.п.;
• сайты вакансий: внимательно читаем, кого ищет ИТ-директор заказчика (в описаниях вакансий зачастую подробно описаны используемые в компании технологии);
• социальные сети: собираем данные на сотрудников-пользователей;
• сайты поставщиков ИТ-решений/услуг, которые хвалятся, что, когда и как сделали для нашего заказчика;
• делаем запросы к сервису whois и выясняем, какие сети зарегистрированы на заказчика или каких провайдеров IP-адресов он использует;
• делаем запросы к DNS-серверам и выясняем, нет ли у заказчика ресурсов с доменами третьего уровня: vpn.ooo-romashka.ru, ftp.ooo-romashka.ru и т.п. Определяем, какие почтовые сервисы используются.

В итоге, мы формируем список IP-адресов информационных ресурсов, связанных с заказчиком, списки сотрудников и др.

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

Шаг 2. Поиск уязвимостей

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

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

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

Шаг 3. Эксплуатация

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

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

Во-вторых, существует множество уязвимостей, которые могут быть проверены только в процессе эксплуатации: например, слабый пароль, возможность SQL-инъекции или XSS.
На данном шаге мы с вами:

• аккуратно запускаем эксплойты;
• перехватываем трафик с помощью ARP-poisoning;
• подбираем пароли;
• «раскручиваем» добытые хеши паролей;
• проверяем на возможность SQL-инъекции/XSS и других атак, специфичных для Web-приложений;
• делаем многое другое в зависимости от конкретной ИТ-инфраструктуры заказчика.

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

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

Шаг 4. Расширение привилегий

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

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

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

Бесплатный инструментарий этичного хакера

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

Безусловным лидером среди подобных инструментов «в одной коробке» является сборка Kali Linux.

Сведем в один список наиболее полезные и чаще всего используемые этичными хакерами бесплатные программы:

• NMAP — сканер портов, может использоваться как сканер уязвимостей и даже средство подбора паролей в случае использования NSE;
• OpenVAS — cканер уязвимостей;
• Metasploit Framework — фреймворк для проведения тестирования на проникновение, содержащий в себе как эксплойты, так и специализированные модули (например, для поиска «расшаренных» папок, для генерации бэкдоров, подбора паролей и т.п.);
• Burp Suite Free Edition — локальный прокси/сканер для анализа защищенности Web-приложений;
• THC-Hydra — утилита для подбора паролей к сетевым сервисам;
• HashCat — утилита для подбора паролей по хешам;
• Ettercap — cниффер для перехвата и анализа сетевого трафика;
• Wireshark — cниффер для перехвата и анализа сетевого трафика;
• Aircrack-ng — набор утилит для тестирования безопасности беспроводных сетей.

Есть еще масса утилит, решающих узкоспециализированные задачи. Неплохой перечень подобных инструментов входит в уже упоминавшуюся сборку Kali Linux: https://tools.kali.org/tools-listing.

Ох уж эта кошмарная командная строка…

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

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

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

Проведение тестирования защищенности с помощью «Сканер-ВС»
Для демонстрации реализации комплексного тестирования защищенности мы рассмотрим процесс анализа виртуальной машины Metasploitable 2

Загружаем «Сканер-ВС» с USB-носителя и открывается главное окно:

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

Внутри каждой фазы доступны соответствующие результаты.

Сканирование портов:

Сканирование уязвимостей с помощью готовых политик или своей собственной. Стоит отметить, что база уязвимостей обновляется еженедельно и содержит плагины для выявления уязвимостей в отечественных СЗИ. Мы также поддерживаем Банк данных угроз ФСТЭК России.

Подбор подходящих экплойтов из Metasploit Framework. Возможен как строгий поиск по версии сервиса, так и нестрогий по его типу.

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

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

Так как «Сканер-ВС» построен на основе Kali Linux, пользователю доступны все стандартные утилиты из данной сборки хакерских инструментов. Также реализованы следующие инструменты, используемые для оценки эффективности средств защиты информации:

• анализ безопасности конфигурации Astra Linux;
• анализ уровня обновлений Windows;
• контрольное суммирование;
• поиск остаточной информации;
• анализ используемого программного и аппаратного обеспечений;
• гарантированное уничтожение информации на диске.

Чтобы дальше не скатываться в прямую рекламу нашей разработки, всех, кому интересно, попробовать наше решение в действии, приглашаем посетить сайт http://scaner-vs.ru и скачать самую последнюю версию решения для тестирования.

Литература и полезные источники информации

1. Техническая методика по тестированию защищенности
2. Еще одна методика по тестированию защищенности
3. Методика по тестированию защищенности Web-приложений
4. Хакерские курсы для начинающих
5. Комплекс тестирования защищенности «Сканер-ВС»

Original source: habrahabr.ru (comments, light).

В данной статье я не буду вам рассказывать о больших веб-фреймворках, таких как React, Angular, Vue и т.д… не будет в ней и перечня наиболее популярных текстовых редакторов – Atom, VS Code, Sublime… В данной статье я поделюсь с вами инструментами, которые, по моему мнению, могут сделать рабочий процесс веб-разработчиков более простым и быстрым.

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

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

Ресурсы

Ghost — Простая платформа для блогов, разработанная с помощью node.js

What runs — Плагин Chrome, предназначенный для изучения технологий, используемых для создания современного веб-сайта



Learn anything — Диаграмма связей для выбора дисциплины (например физика, химия и т.д.) и вывода ее подразделов



LiveEdu.tv — Стриминговый сервис для программистов и дизайнеров, который сфокусирован на реальных проектах. Здесь вы сможете найти сотни каналов по следующим темам: разработка программного обеспечения, искусственный интеллект, наука о данных, разработка игр, дизайн, VR & AR разработка, криптовалюты, на которых разрабатывают реальные проекты, в режиме реального времени и в процессе разработки авторы объясняют каждый шаг.

head cheatsheet — Список всего, что можно включить в тег head

JavaScript библиотеки и фреймворки

Particles.js — Библиотека, в который вы найдете много интересного для создания плавающих элементов на вашей веб-странице.

Three.js — Библиотека для создания на веб-странице 3D-объектов и 3D-визуализации

Fullpage.js — Набор простых для реализации полностраничных скролл-свойств

Typed.js — Эффект пишущей машинки для вашего веб-сайта

Waypoints.js — Примеры кода для запуска функции при прокрутке страницы

Highlight.js — Подсветка синтаксиса для страниц

Chart.js — Набор красивых диаграмм, созданных на чистом JavaScript

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

Chartist — Еще одна библиотека с диаграммами

Motio — Библиотека для создания анимации и панорам с помощью спрайтовой графики

Animstion — Плагин jQuery для создания переходов страниц с помощью CSS

Barba.js — Ресурс для создания перетекающих переходов на странице

TwentyTwenty — Инструмент для создания визуальных различий

Vivus.js — Библиотека для создания начерченных анимаций с помощью SVG

Wow.js — Инструмент для показа рисунков по мере прокрутки страницы

Scrolline.js — Инструмент, благодаря которому вы можете отследить, сколько вам нужно прокрутить до конца страницы

Velocity.js — Инструмент для создания очень быстрых JavaScript-анимаций с плавным переходом

Animate on scroll — Простой пример создания анимаций при прокрутке страницы

Handlebars.js — Разработка шаблонов для JavaScript

jInvertScroll — Эффект горизонтальной прокрутки Parallax

One page scroll — Прокрутка в пределах одной страницы

Parallax.js — Свойство Parallax, реагирующие на ориентацию вашего смарт-устройства

Typeahead.js — Продвинутый поиск и авто-заполнение

Dragdealer.js — Библиотека с множеством крутых эффектов для перемещения анимаций

Bounce.js — Инструмент для создания CSS-анимаций

Pagepiling.js — Прокрутка в пределах одной страницы

Multiscroll.js — Пример кода для создания двух вертикально-прокручивающихся секций

Favico.js — Динамические фавиконы

Midnight.js — Пример кода для изменения неподвижных заголовков при прокрутке страницы

Anime.js — Библиотека различных анимаций для JavaScript

Keycode — JavaScript-код для отображения числовых значений при нажатии клавиш

Sortable — Примеры кода для перетаскивания и удаления элементов на странице

Flexdatalist — Примеры кода для авто-заполнения поиска

JQuerymy — Двусторонняя привязка данных с помощью jQuery

Cleave.js — Форматирование содержимого при наборе текста

Page — Маршрутизация на стороне клиента для одностраничных приложений

Selectize.js — Поля смешанного выбора для добавления тегов

Nice select — Библиотека jQuery для создания красивых полей выбора

Tether — Эффективное прикрепление элементов страницы с абсолютным расположением

Shepherd.js — Путеводитель для пользователей вашего сайта

Tooltip — Название говорит само за себя...

Select2 — Настройка полей выбора с помощью jQuery

IziToast — Простые в реализации JS-уведомления

IziModal — Всплывающие окна, реализованные с помощью простого JavaScript

Библиотеки CSS / Дизайн-инструменты

Animate.css — Библиотека анимаций

Flat UI Colors — Список простых и эффективных цветовых гамм

Material design lite — Фреймворк, основанный на материальном веб-дизайне от Google

Colorrrs — Генератор случайных цветовых гамм

Section separators — Создание границ разных форм с помощью CSS

Topcoat — Фреймворк для создания веб-приложений

Create ken burns effect — Создание эффекта «Ken burns»

DynCSS — Добавление функций в CSS, необходимых для добавления динамических свойств веб-страницам

Magic animations — Что ж, из названия и так все ясно…

CSSpin — Коллекция виртуальных CSS-спиннеров для вашего сайта

Feather icons — Иконки

Ion icons — Иконки

Font awesome — Иконки

Font generator — Эффективный подбор и объединение шрифтов

On/Off switch — Создание переключателя «on/off» с помощью CSS

UI Kit — Фреймворк

Bootstrap — Фреймворк

Foundation — Фреймворк

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

Если вы нашли подобные ресурсы, которые показались вам интересными, оставьте их в комментарии!

Original source: habrahabr.ru (comments, light).

В эту субботу в нашем блоге QIWI на Хабре мы объявили конкурс «По тысяче рублей за идею». Нами предлагалось изложить идею приложения, которое возможно реализовать на базе QIWI API в рамках грядущего всероссийского конкурса QIWI API Contest, а в качестве награды получить за хорошую идею 1000 рублей на свой QIWI Кошелек. Чтобы сбор идей был абсолютно прозрачным, он проходил в комментариях к самой публикации. Несмотря на выходные, пользователи Хабра нас приятно удивили: к реализации было предложено почти два десятка идей.

Победителями конкурса стали пользователи:

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

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

Gorodnya с идеей поддержки приложением QIWI Кошелька функции NFC для перевода денег с банковской карты другого пользователя одним касанием пластика к смартфону.

int27h с идеей автоматизации учёта личных финансов из истории покупок, переводов, платежей, а также автоматической оплаты штрафов и сохраненных сборов.

MrSunny с идеей создания сервиса платных голосований на базе QIWI Кошелька. Плата взимается ради создания еще одного уровня защиты от накруток.

Samouvazhektra с идеей приложения «коллективного кошелька» для сбора средств на определенные нужды. Например, для родителей школьников, студентов и т.д.

Talean с идеей создания кошелька-приложения для сотрудников (курьеров) с автоматической оплатой из расчета пройденного автомобилем пути.

TrusTT с идеей автоматической оплаты услуг SMM-щиков из расчета опубликованных им записей. Данные собираются в «тихом» режиме ботом или предоставляются вручную ссылками. Ориентировано на работу с проверенными людьми.

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

padonnak с идеей создания авторизационного бота в качестве альтернативы СМС-идентификации платежей.

Это — лучшие идеи из опубликованных в комментариях. Однако нам особенно хочется отметить идеи следующих хабраюзеров: Gorodnya, Talean и TrusTT. Их предложения можно прямо сейчас брать и регистрироваться с одним из них на наш конкурс — мы будем рады увидеть реализацию этих предложений. В целом, при отборе победителей мы ориентировались на те идеи, которые можно успешно воплотить в жизнь с использованием открытого API QIWI Кошелька. Причем у всех вышеописанных предложений есть реальный шанс получить главный приз грядущего хакатона — поездку в Сингапур.

Дерзайте! Встретимся на QIWI API Contest.

---

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

Original source: habrahabr.ru (comments, light).

Мы все знаем, что почти каждый iOS-разработчик хотел бы оказаться вечером 12 сентября в театре Стива Джобса в Купертино. Вместо фокусов с телепортацией и материализацией приглашений на это событие мы устроили Avito Special iOS Event.

Сначала послушаем короткие тематические доклады от iOS-разработчиков из ведущих российских компаний, а затем будет совместный просмотр конференции Apple. Специально для Хабра будем вести здесь прямую видеотрансляцию той части, что с докладами, у нас в Avito, а затем — текстовую трансляцию из Калифорнии. Чтобы было ещё веселее, мы подготовили конкурс для тех, кто способен предвидеть будущее.

Итак, под катом:

• прямая трансляция докладов про новые фичи iOS 11 (главным образом про Drag and Drop), ARKit, Vision;
• слайды докладов (скоро появятся);
• конкурс для пользователей Хабра (с 18:00 до 20:00 12.09 по Мск);
• текстовая трансляция конфы (начиная с 20:00 12.09 по Мск);
• свежие картинки с Тимом Куком.

Конкурс

Все большие события Apple окружены атмосферой тайны. Все пытаются угадать, что именно расскажут и покажут на конференции. Предлагаем вам сделать свои ставки в этой форме. Каждый ответ имеет свой вес в баллах. Тому (или тем), у кого наиболее развита интуиция/дар предвидения/etc, мы подарим сувенир от Avito. Ответы закончим принимать с началом трансляции конференции Apple. Теперь — к докладам.

Доклады

Итак, максимально быстро окунаемся в дивный новый мир iOS 11. Мы позвали на митап специалистов из Rabler&Co, Avito и App in the Air. Сегодняшние рассказы — о практическом опыте реализации новых фич iOS 11. Даже если вы сильно не следили за обновлениями, после этого поста вы будете чётко знать, чего не хватает вашим приложениям, чтобы стать полностью iOS 11-совместимыми.

Трансляция из офиса Avito (YouTube)

(UPD 18:28: Мы впервые решили вставить прямую трансляцию с YouTube в пост на Хабре, поэтому ниже уже есть запасная ссылка. Просто на всякий случай).

ARKit в приложении Афиша Рестораны. Самвел Меджлумян, Дмитрий Антышев (Rambler&Co)

Разработчики приложения Афиша Рестораны, Самвел Меджлумян и Дмитрий Антышев, рассказывают о том, как они смогли прикрутить ARKit к своему проекту. Помимо тонны хайпа, видеодемок и кривой Гаттнера много внимания уделено вопросам алгоритмов расчета положения точек в пространстве и построения маршрутов. Если вы до сих пор сомневаетесь, что ARKit можно с пользой встроить в ваше приложение — опыт ребят может помочь вам изменить свое решение.

Анонимизация фото с помощью Vision. Тимофей Хомутников, Avito

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

iOS 11 в App in the Air. Сергей Пронин, App in the Air

Разработчики App in the Air известны тем, что каждый год одними из первых реализуют все новые плюшки из обновления iOS – и неважно, насколько они на первый взгляд релевантны приложению, получается стабильно круто. Этот год тоже не стал исключением. Сергей Пронин, CTO компании, рассказывает про ключевую функциональность, реализованную командой до релиза iOS 11. В нее вошли Drag and Drop, iMessage Live Messages, ARKit, SiriKit и Notifications Privacy.
Особое внимание в докладе Сергей уделяет Drag and Drop. И на примере кейса из своего приложения показывает, что встроить его и кастомизировать для своих нужд достаточно просто.

Купертино live

Текстовая трансляция из телеграм-канала Tolstoy Live будет обновляться и здесь:

• 1:50:03 PM
Всем привет! Смело отписывайтесь от канала — сегодня по мере возможности буду вести трансляцию Apple Special Event для тех, кому лень или некогда смотреть самому. Ну и вообще, началась осень, куча ивентов и все такое.

Бонус

И напоследок бонус: свежие картинки с Тимом Куком. Сделано с любовью.

Пишите в комментариях, что думаете о сегодняшней конференции, докладах и практическом применении iOS 11!

Original source: habrahabr.ru (comments, light).

Последнее время я часто рассказываю про контейнеры, Docker и Kubernetes. На фоне этого коллеги всё чаще стали спрашивать о том, а где же здесь технологи Microsoft? Чтобы объяснить, я нашёл несколько материалов, в том числе этот набор из пары статей от Colin Dembovsky. В них есть всё: Docker, Kubernetes и наши технологии. Думаю, что для читателей Хабры это тоже должно быть интересно. Итак, встречайте, перевод первой части.



Если вы читаете мой блог, то знаете, что я фанат контейнеров в целом и Docker в частности. Когда вы в последний раз ставили софт на «голое железо»? Может быть, только на ноутбук, но и то шансы невелики. Виртуализация кардинально изменила наше отношение к ресурсам центра обработки данных, значительно увеличив их плотность и эффективность использования. Следующим этапом повышения плотности стали контейнеры, только ВМ размещаются на физических серверах, а контейнеры — в самих ВМ. Очень скоро большинство из нас не будет работать не только на уровне серверов, но даже на уровне ВМ, все рабочие нагрузки переместятся в контейнеры. Но это в перспективе.

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

В этой статье мы рассмотрим подходы к локальной разработке с использованием Kubernetes и minikube. Часть 2 посвящена вопросам создания конвейеров CI/CD для кластера Kubernetes в Azure.

Поле битвы — оркестрация

Существуют три популярные системы оркестрации контейнеров — Mesos, Kubernetes и Docker Swarm Mode. Я не буду призывать вас встать под чей-то флаг (по крайней мере пока), концептуально они все похожи. Они все используют концепцию «конфигурация как код» для развертывания множества контейнеров на множество узлов. Kubernetes предлагает ряд возможностей, которые, на мой взгляд, станут настоящим прорывом в области DevOps: карты конфигурации (ConfigMaps), секреты (Secrets) и пространства имен (namespaces).

Не вдаваясь в подробности, скажу, что пространства имен позволяют создавать различные логические среды в одном кластере. В качестве примера приведу пространство имен DEV, где вы сможете запускать небольшие копии своей среды PROD в целях тестирования. Пространства имен также применяются для реализации мультитенантности или различных контекстов безопасности. Карты конфигурации (ConfigMaps) и секреты (Secrets) позволяют хранить конфигурацию за пределами контейнеров, то есть вы сможете запускать один образ в различных контекстах без встраивания специфичного кода для конкретной среды в сами образы.

Kubernetes Workflow (рабочий процесс) и Pipeline (конвейер)

В этой статье я продемонстрирую подход к разработке с ориентацией на Kubernetes. В первой части мы рассмотрим рабочий процесс разработки, а во второй — конвейер DevOps. К счастью, благодаря MiniKube (кластеру с одним узлом Kubernetes, который запускается на ВМ) мы можем работать с полноценным кластером на ноутбуке! Это означает, что вам доступны преимущества кластерной технологии (вроде ConfigMaps) без подключения к производственному кластеру.

Итак, рассмотрим рабочий процесс разработчика. Это будет что-то вроде:

1. Разработать код.
2. Создать образ на основе файла Dockerfile или пакета файлов, сформированного с помощью команды docker-compose.
3. Запустить службу в MiniKube (запускаем контейнеры из ваших образов).

Как показывает практика, благодаря Visual Studio 2017 (и (или) VS Code), Docker и MiniKube на этом пути вам не встретятся подводные камни.

Затем вы перейдете к конвейеру DevOps, начиная с его создания. На основе ваших исходных файлов и файлов Dockerfile создаются образы, которые регистрируются в приватном реестре контейнеров. Далее необходимо передать конфигурацию в кластер Kubernetes, чтобы запустить/развернуть новые образы. Благодаря Azure и VSTS мы создадим конвейер DevOps буквально за пару-тройку кликов! Но это тема второй части нашей статьи, сейчас же мы изучаем рабочий процесс разработчика.

Подготовка среды разработки

Для демонстрации я буду использовать Windows, но в Mac или Linux настройки аналогичные. Для развертывания локальной среды разработки вам нужно установить:

1. Docker
2. Kubectl
3. MiniKube

Можете воспользоваться ссылками и выполнить установку. В процессе я столкнулся с небольшой проблемой при запуске MiniKube на Hyper-V — по умолчанию команда MiniKube start, создающая ВМ для MiniKube, подключается к первой найденной виртуальной сети Hyper-V. Сетей у меня было несколько, и MiniKube подключился ко внутренней, что привело к сбою. Я создал новую виртуальную сеть с именем minikube в консоли Hyper-V и убедился, что это внешняя сеть. Для создания ВМ MiniKube я воспользовался следующей командой:

c:
cd \
minikube start --vm-driver hyperv --hyperv-virtual-switch minikube

Мне пришлось выполнить команду cd для перехода в корневой каталог c:\, без этого MiniKube не смог бы создать ВМ.

Внешняя сеть подключена к моей точке доступа Wi-Fi. Это означает, что когда я подключаюсь к новой сети, ВМ minikube получает новый IP-адрес. Вместо того чтобы каждый раз обновлять kubeconfig, я просто добавил строку хоста в свой файл hosts (в Windows это c:\windows\system32\drivers\etc\hosts): kubernetes, где IP — это IP-адрес ВМ minikube, полученный с помощью команды minikube ip. Для обновления kubeconfig используйте следующую команду:

kubectl config set-cluster minikube --server=https://kubernetes:8443 --certificate-authority=c:/users//.minikube/ca.crt

где — ваше имя пользователя; таким образом, cert указывает на файл ca.crt, созданный в вашем каталоге .minikube.
Теперь при подключении к новой сети вы просто обновите IP-адрес в файле hosts, и команда kubectl по-прежнему будет работать. Сертификат генерируется для узла с именем kubernetes, поэтому используйте это имя.

Если все работает нормально, вы получите лаконичный ответ на команду kubectl get nodes:

PS:\> kubectl get nodes
NAME       STATUS    AGE       VERSION
minikube   Ready     11m       v1.6.4

Чтобы запустить UI Kubernetes, просто введите команду minikube dashboard. В браузере откроется следующее окно:



Наконец, для «повторного использования» контекста minikube docker выполните следующую команду:

minikube docker-env | Invoke-Expression

Таким образом обеспечивается совместное использование сокета minikube docker. Выполнив команду docker ps, вы получите информацию о нескольких работающих контейнерах, это базовые системные контейнеры Kubernetes. Это также означает возможность создания здесь образов, которые могут запускаться кластером minikube.

Теперь у вас есть кластер с одним узлом. Можете приступать к разработке!

Переходим к коду

Не так давно я опубликовал в блоге статью Разработка проекта Aurelia с помощью Azure и VSTS. И поскольку у меня уже была пара готовых сайтов .NET Core, я решил попробовать запустить их в кластере Kubernetes. Выполните клонирование этого репозитория и проверьте ветку docker. Я добавил несколько файлов в репозиторий, чтобы обеспечить возможность создания образов Docker и указать конфигурацию Kubernetes. Давайте посмотрим, как это выглядит.

Файл docker-compose.yml определяет составное приложение из двух образов: api и frontend:

version: '2'

services:
  api:
    image: api
    build:
      context: ./API
      dockerfile: Dockerfile

frontend:
    image: frontend
    build:
      context: ./frontend
      dockerfile: Dockerfile

Файл Dockerfile для каждой службы максимально прост: запуск из образа ASP.NET Core 1.1, копирование файлов приложения в контейнер, открытие порта 80 и запуск dotnet app.dll (frontend.dll и api.dll для каждого сайта) в качестве точки входа для каждого контейнера:

FROM microsoft/aspnetcore:1.1
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "API.dll"]

Чтобы подготовиться к созданию образов, выполните команды dotnet restore, build и publish, произойдёт сборка и публикация проектов. Теперь можно переходить к созданию образов. При наличии готовых образов мы можем настроить службу Kubernetes на их запуск в нашем кластере minikube.

Создание образов

Проще всего для создания образов использовать Visual Studio. Настройте проект docker-compose как стартовый и запустите его. Образы будут созданы. Если вы не работаете с Visual Studio, создавайте образы, выполняя следующие команды из корневого каталога репозитория:

cd API
dotnet restore
dotnet build
dotnet publish -o obj/Docker/publish
cd ../frontend
dotnet restore
dotnet build
dotnet publish -o obj/Docker/publish
cd ..
docker-compose -f docker-compose.yml build

Теперь после выполнения команды docker images вы увидите контейнеры minikube, а также образы для frontend и api:

Объявление служб — конфигурация как код

Теперь мы можем указать, какие службы запускать в кластере. На мой взгляд, одно из преимуществ Kubernetes заключается в том, что вы должны объявлять свою среду, вместо того чтобы запускать скрипт. Такая декларативная модель намного лучше императивной, и в настоящее время она распространяется все шире благодаря Chef, Puppet и PowerShell DSC. Kubernetes позволяет нам указывать запускаемые службы, а также определять методы их развертывания. Различные объекты Kubernetes можно определять с помощью простого файла yaml. Мы объявляем две службы: api и frontend. Серверные службы (backend) обычно недоступны за пределами кластера, однако в данном случае наш демонстрационный код представляет собой одностраничное приложение, поэтому служба api должна быть доступна извне.

Перечень служб будет меняться очень редко, это службы, доступные в кластере. Однако базовые контейнеры (в Kubernetes их называют подами), из которых состоит служба, будут меняться. Они меняются при обновлении, а также при масштабировании. Для управления контейнерами, из которых состоит служба, используется конструкция Deployment. Поскольку служба и развертывание довольно тесно связаны, я поместил их в один файл. То есть у нас есть файл для службы/развертывания frontend (k8s/app-demo-frontend-minikube.yml) и файл для службы/развертывания api (k8s/app-demo-backend-minikube.yml). Если вы посчитаете нужным, можете поместить определения служб и развертываний в отдельные файлы. Изучим содержимое файла app-demo-backend.yml:

apiVersion: v1
kind: Service
metadata:
  name: demo-backend-service
  labels:
    app: demo
spec:
  selector:
    app: demo
    tier: backend
  ports:
    - protocol: TCP
      port: 80
      nodePort: 30081
  type: NodePort
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo-backend-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: demo
        tier: backend
    spec:
      containers:
      - name: backend
        image: api
        ports:
        - containerPort: 80
        imagePullPolicy: Never

Примечания:

• Строки 1–15 объявляют службу.
• В строке 4 указано имя службы.
• В строках 8–10 описан селектор для этой службы. Любой под с метками app=demo и tier=frontend будет использоваться для балансировки нагрузки этой службы. Служба будет знать, как перенаправить на свои базовые модули трафик, связанный с запросами для этой службы, которые попадают в кластер. Это упрощает добавление, удаление и обновление контейнеров, поскольку все, что нам нужно сделать, — изменить селектор. Служба получит статический IP-адрес, а ее базовые модули — динамические адреса, которые будут меняться на разных этапах жизненного цикла модулей. Тем не менее этот процесс абсолютно прозрачен для нас, потому мы будем просто посылать запросы службе, и все должно работать.
• Строка 14 — мы хотим, чтобы эта служба была доступна через порт 30081 (сопоставленные с портом 80 на подах, как указано в строке 13).
• Строка 15 — NodePort указывает, что мы хотим, чтобы Kubernetes предоставлял службе порт на том же IP-адресе, который использует кластер. Для «реальных» кластеров (на ресурсах поставщика облачных услуг, например Azure) мы изменили бы эту настройку, чтобы получить IP-адрес от облачного хоста.
• В строках 17–34 объявляется конструкция Deployment, которая обеспечит наличие контейнеров (подов) для этой службы. Если под неработоспособен, Deployment автоматически запускает новый под. Эта конструкция гарантирует нормальную работу службы.
• Строка 22 указывает, что нам постоянно требуются два экземпляра контейнера для этой службы.
• Строки 26 и 27 важны, они должны соответствовать меткам селектора из службы.
• В строке 30 указано имя контейнера в поде (в нашем случае в этом поде всего один контейнер, как мы и планировали).
• В строке 31 указано имя запускаемого образа — это же имя мы указали в файле docker-compose для образа backend.
• В строке 33 мы открываем порт 80 на этом контейнере для кластера.
• Строка 34 указывает, что мы не хотим, чтобы Kubernetes извлекал образ, поскольку собираемся создавать образы в контексте minikube docker. В производственном кластере мы планируем указать другие политики, чтобы кластер мог получать обновленные образы из реестра контейнеров (мы увидим это во второй части).

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

spec:
  containers:
    - name: frontend
      image: frontend
      ports:
      - containerPort: 80
      env:
      - name: "ASPNETCORE_ENVIRONMENT"
        value: "Production"
      volumeMounts:
        - name: config-volume
          mountPath: /app/wwwroot/config/
      imagePullPolicy: Never
  volumes:
    - name: config-volume
      configMap:
        name: demo-app-frontend-config

Примечания:

• Строка 30: имя контейнера в поде.
• Строка 31: укажите имя образа для этого контейнера, оно должно совпадать с именем в файле docker-compose.
• Строки 34–36: пример указания переменных среды для службы.
• Строки 37–39: ссылка для монтирования тома (указано ниже) для подключения файла конфигурации, из которого Kubernetes узнает, где в файловой системе контейнера должен быть смонтирован файл. В данном случае Kubernetes смонтирует том с именем config-volume по следующему пути в контейнере: /app/wwwroot/config.
• Строки 41–44: они указывают том, в нашем случае — том configMap для конфигурации (подробнее об этом чуть ниже). Здесь мы просим Kubernetes создать том с именем config-volume (на который ссылается volumeMount контейнера) и использовать для тома данные из configMap с именем demo-app-frontend-config.

Управление конфигурацией

Теперь у нас есть несколько образов контейнеров и мы можем запускать их в minikube. Но прежде чем начать, давайте обсудим конфигурацию. Если вы слышали мои выступления или читали мой блог, то вы знаете, что я — один из главных пропагандистов концепции «создаем один раз, разворачиваем многократно». Это базовый принцип правильного DevOps. В случае с Kubernetes и контейнерами ситуация аналогичная.

Однако для этого вам нужно будет размещать конфигурацию за пределами своего скомпилированного кода, то есть понадобятся такие механизмы, как файлы конфигурации. Если вы выполняете развертывание в службах IIS или Azure App, то можете просто использовать файл web.config (для DotNet Core это будет appsettings.json) и указать разные значения для разных сред. Но как тогда быть с контейнерами? Весь код приложения находится в контейнере, поэтому вы не можете использовать разные версии конфигурационного файла, в противном случае вам понадобятся разные версии самого контейнера, то есть принцип однократного создания будет нарушен.

К счастью, мы можем использовать подключаемые тома (концепция контейнеров) в сочетании с секретами и (или) configMaps (концепция Kubernetes). Мы можем указать configMaps (по сути это пары ключ — значение) или секреты (маскированные или скрытые пары ключ — значение) в Kubernetes, а затем просто смонтировать их путем подключения томов в контейнерах. Это действительно мощный инструмент, поскольку определение пода остается прежним, но если у нас есть другой configMap, мы получаем другую конфигурацию! Мы увидим, как это работает, когда будем выполнять развертывание в облачном кластере и использовать пространства имен для изоляции среды разработки и производственной среды.

configMaps также можно указать с помощью метода «конфигурация как код». Вот конфигурация нашего configMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-app-frontend-config
  labels:
    app: demo
    tier: frontend
data:
  config.json: |
    {
      "api": {
        "baseUri": "http://kubernetes:30081/api"
      }
    }

Примечания:

• Строка 2: мы указываем, что это определение configMap.
• Строка 4: имя этой карты.
• Строка 9: мы указываем, что эта карта использует формат file format, и задаем имя файла — config.json.
• Строки 10–14: содержимое конфигурационного файла.

Отступление: проблема символьных ссылок на статические файлы

Я действительно столкнулся с одной проблемой при монтировании конфигурационного файла с помощью configMaps: внутри контейнера путь /app/www/config/config.json оканчивается символической ссылкой. Идею использовать configMap в контейнере я подсмотрел в отличной статье Энтони Чу (Anthony Chu), где он описывает, как подключал файл application.json для использования в файле Startup.cs.

Очевидно, с проблемой символической ссылки в файле Startup он не сталкивался. Однако для своего демонстрационного клиентского приложения я создаю конфигурационный файл, который используется SPA-приложением, и поскольку он находится на стороне клиента, конфигурационный файл должен предоставляться из приложения DotNet Core, просто в виде html или js. Нет проблем. У нас уже есть вызов UseStaticFiles в Startup, поэтому он должен просто предоставлять файл, верно? К сожалению, это не так. Скорее всего, он перешлет только первые несколько байтов из этого файла.

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

Запуск образов в Kubernetes

Чтобы запустить вновь созданные службы в minikube, мы можем просто использовать kubectl для применения конфигураций. Вот список команд (выделенные строки):

PS:\> cd k8s
PS:\> kubectl apply -f .\app-demo-frontend-config.yml
configmap "demo-app-frontend-config" created
 
PS:\> kubectl apply -f .\app-demo-backend-minikube.yml
service "demo-backend-service" created
deployment "demo-backend-deployment" created
 
PS:\> kubectl apply -f .\app-demo-frontend-minikube.yml
service "demo-frontend-service" created
deployment "demo-frontend-deployment" created

Теперь у нас есть службы! Вы можете открыть информационную панель командой minikube dashboard и убедиться, что статус служб — зеленый:



Чтобы подключиться к клиентской службе, введите адрес http://kubernetes:30080:

Список (value1 и value2) — это значения, возвращаемые службой API, то есть клиент смог успешно подключиться к серверной службе в minikube!

Обновление контейнеров

После обновления своего кода вам придется пересоздавать контейнер(ы). Обновив конфигурацию, снова запустите команду kubectl apply для обновления configMap. Затем, поскольку нам не нужна высокая доступность в среде разработки, мы можем просто удалить запущенные поды и дать возможность службе репликации перезапустить их, но на этот раз с обновленной конфигурацией и (или) кодом. Конечно, в производственной среде такие вольности недопустимы, и во второй части я покажу вам, как выполнять последовательные обновления, когда мы будем работать с CI/CD в кластере Kubernetes.

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

PS:> kubectl get pods
NAME                                       READY     STATUS    RESTARTS   AGE
demo-backend-deployment-951716883-fhf90    1/1       Running   0          28m
demo-backend-deployment-951716883-pw1r2    1/1       Running   0          28m
demo-frontend-deployment-477968527-bfzhv   1/1       Running   0          14s
demo-frontend-deployment-477968527-q4f9l   1/1       Running   0          24s
 
PS:> kubectl delete pods demo-backend-deployment-951716883-fhf90 demo
-backend-deployment-951716883-pw1r2 demo-frontend-deployment-477968527-bfzhv demo-frontend-deployment-477968527-q4f9l
pod "demo-backend-deployment-951716883-fhf90" deleted
pod "demo-backend-deployment-951716883-pw1r2" deleted
pod "demo-frontend-deployment-477968527-bfzhv" deleted
pod "demo-frontend-deployment-477968527-q4f9l" deleted
 
PS:> kubectl get pods
NAME                                       READY     STATUS    RESTARTS   AGE
demo-backend-deployment-951716883-4dsl4    1/1       Running   0          3m
demo-backend-deployment-951716883-n6z4f    1/1       Running   0          3m
demo-frontend-deployment-477968527-j2scj   1/1       Running   0          3m
demo-frontend-deployment-477968527-wh8x0   1/1       Running   0          3m

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

Заключение

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

---

P.s. Благодарим Константина Кичинского (Quantum Quintum) за иллюстрацию к этой статье.

Original source: habrahabr.ru (comments, light).

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

Правила

1. Дизайн должен быть единым, независимо от платформы

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



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

2. Простая и понятная навигация

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

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

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

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



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

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

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



Z-образный паттерн на сайте Basecamp

5. Проверяйте ссылки!
Пользователь теряет доверие к сайту каждый раз, когда по ссылке вылетает ошибка 404 (несуществующая страница). Кликая по ссылке, пользователь ждет решения проблемы, а не сообщение об ошибке.



Страница не найдена

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



Menagerie Climb: оранжевый бокс — это кнопка? Нет. Хотя форма и вид говорит об обратном

Запреты

1. Заставлять посетителя ждать загрузки страницы
Запас терпения и способность концентрировать внимание пользователя очень малы. Об этом говорится в исследовании NNGroup:

Предельное время концентрации пользователя на задаче — 10 секунд

Если пользователь вынужден ждать загрузки сайта, он теряет терпение и может уйти. Даже самый красивый индикатор загрузки не сможет удержать его надолго.



Изображение: Ramotion

2. Открывать ссылку в новой вкладке
Такой способ грубо отключает сценарий использования кнопки «назад» для возврата на предыдущую страницу.



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



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



На странице Mac Pro ужасная прокрутка: точки под картинкой ведут каждая на свою секцию страницы

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


Видео на Facebook включаются автоматически, но без звука, до тех пор, пока пользователь не подтвердит, что смотрит видео (кликнув по нему)

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



Неконтрастные шрифты — это всегда плохая идея

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



Избегайте мигающего текста!

Original source: habrahabr.ru (comments, light).

Всем привет. Меня зовут Игорь Акимов, я руководитель направления мобильных продуктов ABBYY. Наверное, многие знают ABBYY по лучшим словарям Lingvo и помощнику любого студента FineReader, но кроме этого мы занимаемся ещё много чем интересным в сфере интеллектуальной обработки информации и лингвистики. За 28 лет накопили огромный багаж в сфере машинного обучения и нейросетей, а новых проектов и идей так много, что кажется, нам нужна помощь :) Поэтому мы приглашаем вас принять участие в конкурсе. Мы ищем идеи по применению новых технологий в мобильной разработке, которые будут близки большому числу людей. И назвали конкурс мы смело – mABBYYlity (тут и ABBYY, и мобильность, и ability – способность). Короче, всё основное тут – mobility.abbyy.com. А в статью за подробностями.

Почему идеи?

Итак, конкурс идей от ABBYY. Есть мнение, что реализация идеи, особенно в стартапе, гораздо важнее гениального озарения. Но идея с точки зрения человеческого знания – настоящий акт творения, перенос в наш мир вещей чего-то абсолютно нового. Это вызывает уважение! Мы понимаем, что можем решить множество интересных задач образования и бизнеса, но какие из них действительно самые интересные и полезные? Вы, стоя на самой кромке края этого процесса, знаете о нём гораздо больше лучше наших клиентов и сотрудников. А потому нам важно ваше мнение о том, как сделать мир лучше с помощью технологий ABBYY.

Понимаем, что просто так взять и придумать или скомбинировать что-то новое сложно, а потому есть весь остаток сентября на подумать. Заявки принимаются до 30 сентября, а о результатах скажем довольно быстро – 7 октября (да, наша команда будет спать в офисе эту неделю). Ну и плюс можно будет реализовать идею на хакатоне, который мы анонсируем чуть позднее.

Зачем вообще участвовать?

Когда я учился в вузе на 3 курсе, помню, сделал для студентов бесплатную рассылку расписания через SMS (GMS-модем и небольшая программулина с базой), потому что серверные API для этого были просто люто неудобные и дорогие. Уверен, что и вы видите крутые масштабные возможности каждый день, возможно, пользуетесь нашими продуктами и уверен, часто думаете, как было бы круто, если бы сейчас в ABBYY запилили … Теперь такая возможность есть!
Ну и конечно, не обделим мы самых творческих и призами. Главная радость — новейший iPhone Edition, который ещё даже не представлен (купим за любые деньги и подарим вам).

Направления идей

Итак, давайте пробежимся по направлениям, которыми мы занимаемся сами и видим большой потенциал:

Боты, сервисы в социальных сетях и мессенджерах

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

Дополненная реальность в мобильных устройствах

С iOS 11 практически на миллионах девайсов будут открыты возможности простой в разработке и довольно качественной дополненной реальности с помощью ARKit и мы конечно же добавим интересную штуку в наши мобильные приложения (следите за анонсами), а буквально неделю назад случился ответный ход Google с ARCode и стало ясно, что это всерьёз и надолго. Дополненную реальность в бизнесе пока можно слабо связать с какой-либо полезностью (кроме 3d-моделирования и архитектуры), но я уверен, что полезные сценарии есть.

Обработка текстов, классификация документов, поиск

О, тут можно много чего рассказывать. Во-первых, есть интеллектуальные технологии ABBYY, которые позволяют в слабоструктурированных текстах искать взаимосвязи и выделять сущности. Во-вторых, нейросеточки ещё больше улучшают результаты работы и упрощают получение хороших данных. Здесь желательно использовать всё, что хорошо конвертится в CoreML – Caffe, TensorFlow, Keras, scikit-learn 0.18, XGBoost 0.6, LIBSVM 3.22.

Распознавание и обработка изображений и видео

Это альфа и омега ABBYY. В распознавании мы съели уже столько собак, что кажется, что удивить уже нечем, но нет :) С каждой новой научной статьёй и патентом наших инженеров понимаю, что развиваться ещё есть куда. Самый важный анонс последнего времени – это Real-Time Recognition – распознавание в реальном времени, а значит и быстро, и качественно, и из видеопотока. Сценариев тут много: от сканирования документов и пропусков до перевода текста в незнакомой стране в дополненной реальности.

Улучшение, дополнение, фильтрация фотографий

Чтобы качество распознавания росло и документ даже в самых дичайших условиях съёмки выглядел так, как будто экспортирован из только что свежераспечатанного Word-а, нужно много чего полезного сделать с фотографией: от подбора правильного фильтра до определения, где же на фото картиночки, а где наш замечательный текст. Ну и конечно поиск из нескольких фотографий самой крутой для распознавания, или, например, поиск фотографий паспорта в вашей ленте – тоже актуальные задачи, которые мы решаем каждый день. И ваши идеи тоже будут к месту.

Распознавание и обработка изображений в браузере

Браузеры развиваются такими темпами, что кажется, что “не будет скоро ни балета, ни театра, одно сплошное телевидение” – в браузерах будут работать все. И тут можно подумать о технологии WebAssembly, а также обо всех крутых JavaScript-библиотеках, которые занимаются распознаванием и обработкой изображений.

Распознавание в камерах различных устройств

Сканером в телефоне уже никого не удивить (есть же FineScanner), а вот разные дроны, роботы, дорожные камеры и автомобили – другой зверь. Пролетая дроном над гнездом кукушки, можно, например, считать кукушат, а также (что более полезно) – распознавать номера вагонов.

Технологии обмена информацией

Получив информацию в одном месте не всегда получается быстро передать её, куда нужно. Попытки придумать колесо здесь идут о-о-очень давно. Можно вспомнить ту же передачу данных на мобильниках. Сначала по инфракрасному порту (ох, до сих пор помню, как заливал рингтоны в Siemens S35i и Samsung аж с 16 инструментами!), потом по Bluetooth, потом Wi-Fi Direct, NFC, AirDrop, облака и так далее и тому подобное. А счастья всё нет. То же и со связкой мобилки с десктопом. Десятки прикольных технологий, но идёт со скрипом… Но вместе с вами победим!

Технологии повышения безопасности

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

Цифровое предприятие, повышение продуктивности

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

Облачные технологии и сервисы

Для мобилок облака – единственная возможность манипулировать гигантскими объемами данных и распрямлять, например, загнутые страницы книги, как это делает BookScanner. Можно как придумать такой сервис, так и “прикрутить” хорошее API к нашим текущим технологиям. Разных идей и комбинаций миллион.

Как и кто оценивает?

Мы старались не перегружать заявку лишним, но постараться выбрать наиболее жизнеспособные вещи. А потому критериев 4:

1. Актуальность (проблема не решена полноценно, а на костыльные решения тратятся миллионы);
2. Новизна и оригинальность (конкуренты пока спят);
3. Техническая (технологическая) реализуемость (можно сделать на уровне прототипа за пару дней – отлично!);
4. Оценка рыночного потенциала (каждый день сталкиваются миллионы людей).

В экспертное жюри конкурса постарались подобрать людей, которые оценят идеи с разных сторон. Их в итоге 6:

• Вице-президент по продуктовому маркетингу ABBYY Сергей Павлов;
• Директор по продуктам группы компаний ABBYY Андрей Исаев;
• Ваш покорный слуга – руководитель отдела мобильных продуктов ABBYY Игорь Акимов;
• Управляющий инвестиционным портфелем ФРИИ Сергей Негодяев;
• Главный редактор технологического лайфстайл-ресурса TechFusion.ru Марина Эфендиева;
• Директор по развитию и международным отношениям Физтехпарка Екатерина Елисеева.

Вроде всё. Если будут какие-то вопросы – пишите, отвечу в комментариях.
Заходите в группы конкурса VK, Facebook и Telegram

Ну и обязательно расскажите о своей идее тут mobility.abbyy.com.

Original source: habrahabr.ru (comments, light).

Нельзя сказать, что я не искал с этим демоном встречи. Я дождался пока он вылезет и выследил его логово. Поиграл с ним немного. Потом демон исчез, как обычно, по расписанию — в 9.00. Я успокоился и занялся своими бытовыми делами.

Дело было в том, что у нас в Питере не найти в книжных магазинах рабочую тетрадь по английскому языку "Планета знаний" 3 класс. Ну как в Союзе было, дефицит. И мне жена дала задание — зайти в книжные в Москве. Дескать, в столице все есть, тетки на форуме оттуда заказывают, платят 500 рублей за доставку, а ты, пользуясь случаем, купишь сам и сэкономишь для семьи. Хоть какой-то толк от неудачника будет. Я включаю Гугль-карту, задаю фразу "книжные магазины" и не понимаю. Ни Красной площади, ни реки, какие-то непонятные улицы.

Черт! Он вылез опять! Я ведь еще успел только до Варварки дойти.

И, повинуясь зову природы, я расчехлил опять свое оружье.

Пока расчехляю — думаю так.

Он ведь, собака, мешает мне жить, выполнять простые бытовые надобности. И всем этим туристам, которые поднимаются из Китай-города на площадь тоже мешает. И тем парням, которые на Кремлевской набережной попали в ДТП тоже мешает. И бегунам, и таксистам, и их пассажирам. И еще многим людям, о которых я не вспомнил. А кто это у нас в России отвечает за радио частоты? Чтобы чисто все было, без помех. Кажется ГРЧЦ называется, Главный Радичастотный Центр. И сайт у него имеется — http://www.grfc.ru/grfc/. И он ведь может по массовой жалобе, например, людей в интернете проверить наличие демона и найти его, но не делает. А ну как президент спросит на следующей прямой линии, кто это кошмарит его население. Но я эти Радичастотные Центры могу понять. У них на носу мероприятие мощное в месте хорошем, на природе — Спектр-Форум. Бархатный сезон, курортный роман и все такое. Обсудят там чистоту спектра и с новыми силами за работу. Эх, где мои шестнадцать лет...

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

Оружье мое выглядит так:

Про его внутреннее устройство можно прочитать в моей предыдущей статье.

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

Пеленгатор подключается к планшету по USB3, а у него требования к качеству кабеля довольно серьезные. Благо кабель у меня должен быть не очень длинный, я беру кусочки простой витой пары UTP и соединяю разъем типа A с разъемом типа C. На пеленгаторе стоит тип C, так как нельзя толщину сильно увеличивать, будет некрасиво. Получается вот такая скрутка всех цветов радуги. И самое главное — надо добавить еще отдельных земляных проводов в эту скрутку. С одним, например, даже на такой длине USB-интерфейс выдает ошибки и связи с платой нет.

На стороне A все очень просто.

А на стороне C нужен еще резистор (согласно стандарта на type C), который я в формате SMD не нашел, поэтому поставил большой советский. Вот как спасают иногда старые запасы наших отцов!

Вернемся же к нашему подопечному, пока вы совсем не заскучали. Разные мобильные устройства реагируют на демона сильно по разному. У меня на руках был Samsung Duos и Lenovo Phab 2 Pro (звезда будущих статей про AR-пеленгаторы). Samsung даже в непосредственной близости от демона редко улетал во Внуково. Он просто не мог найти навигационное решение. Экран его GPSTest выглядел так:

Здесь особо примечательно то, что значение ОСШ (SNR) около 50 дБ на этом смартфоне не бывает в принципе. Потери в антенне этого устройства приводят к довольно большому системному коэффициенту шума (System Noise Floor). Я при открытом небе видел всего 40 дБ с небольшим. И это является одним из признаков пришествия демона, наблюдаемым на обычных мобильных устройствах.

Еще необходимо заметить, что, наряду с поддельными спутниками, принимаются и настоящие. У них ОСШ (SNR) значительно меньше. Правый скриншот снят под Москворецким мостом, поэтому там есть только один настоящий спутник, но остальные (поддельные) принимаются так, как будто они все у меня в кармане.

А вот более новый гаджет — Lenovo Phab 2 Pro тупо показывает Внуково:

Вот в этот гаджет я и вставил московскую СИМку и планировал нормально ориентироваться в Москве. Но ...

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

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

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

На первом я спускаюсь по парку Зарядье, который отмывают от строительной грязи. Это поэтому у меня ботинки такие грязные.

На втором я прогуливаюсь по Кремлевской набережной.

Я внимательно читал статью на Медузе и не вижу смысла не верить авторам. Раз коллеги нашли демона там, значит он там и был.

Просто он переехал.

P.S.
Может мой Phab 2 Pro так завис, но я увидел, что демон пропал только в 10.30, ровно. И было это аж возле хакспейса Нейрон на Хохловском. Меня удивляет и возмущает, как же далеко он бьет. Зачем? Также я подозреваю демона в формализме. Почему он включается и выключается в моменты времени, кратные часу или получасу? Нехорошо все это. Демон, надо бы поберечь население.

Original source: habrahabr.ru (comments, light).

Прочитав статью Episode 8: Interview with Ryan Dahl, Creator of Node.js и комментарии к переводу, я решил протестировать эффективность блокирующей и неблокирующей операции чтения файла в Node.js, под катом таблицы и графики.

Блокирующая операция (fs.readFileSync одна из таких) предполагает что исполнение всего приложения будет приостановлено пока не связанные с JS на прямую операции не будут выполнены.

Неблокирующие опрации позволяют выполнять не связанные с JS операции асинхронно в параллельных потоках (например, fs.readFile).

Больше об blocking vs non-blocking здесь.

Хоть Node.js исполняется в одном потоке, с помощью child_process или cluster можно распределить исполнение кода на несколько потоков.

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

При чтении 3.3 kB файла 10 000 раз

Symbol	Name	ops/sec	Percents
A	Loop readFileSync	7.4	100%
B	Promise chain readFileSync	4.47	60%
C	Promise chain readFile	1.09	15%
D	Promise.all readFileSync	4.58	62%
E	Promise.all readFile	1.69	23%
F	Multithread loop readFileSync	1.35	18%

При чтении 3.3 kB файла 100 раз

Symbol	Name	ops/sec	Percents
A	Loop readFileSync	747	100%
B	Promise chain readFileSync	641	86%
C	Promise chain readFile	120	16%
D	Promise.all readFileSync	664	89%
E	Promise.all readFile	238	32%
F	Multithread loop readFileSync	1.55	0.2%

При чтении 6.5 MB файла 100 раз

Symbol	Name	ops/sec	Percents
A	Loop readFileSync	0.63	83%
B	Promise chain readFileSync	0.66	87%
C	Promise chain readFile	0.61	80%
D	Promise.all readFileSync	0.66	87%
E	Promise.all readFile	0.76	100%
F	Multithread loop readFileSync	0.56	74%

Загрузка процессора при чтении 3.3 kB файла 10 000 раз (без Multithread loop readFileSync)

Загрузка процессора при чтении 6.5 MB файла 100 раз

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

Следовательно, чтение небольших файлов лучше проводить с помощью fs.readFileSync, а больших файлов с помощью fs.readFile (насколько файл должен быть большой зависит от компьютера и софта).

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

Пример ситуации чтения файла.

Допустим у нас крутится веб сервер на ноде в одном потоке T1. На сервер одновременно приходит два запроса (P1 и P2) чтения и обработки небольших файлов (по одному на запрос). При использовании fs.readFileSync последовательность исполнения кода в потоке Т1 будет выглядеть так:

P1 -> P2

При использовании fs.readFile последовательность исполнения кода в потоке Т1 будет выглядеть так:

P1-1 -> P2-1 -> P1-2 -> P2-2

Где P1-1, P2-1 — делегирование чтения в другой поток, P1-2, P2-2 — получение результатов чтения и обработка данных.

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

Original source: habrahabr.ru (comments, light).

Компания Redmadrobot как участник программы Certification of Development Agencies от Google получила несколько билетов на Google Developers Days Europe. Мы делимся своим мнением о программе, докладах и атмосфере конференции.




Конференция длилась 2 дня и проходила в 5 трэков: 2 трэка с докладами, 2 с воркшопами и 1 комьюнити. Доклады частично пересекались с прошедшим I/O, по некоторым из них стало понятно, на сколько продвинулся Google в каждой из дисциплин.




Блинов Александр (@Xanderblinov), ведущий Android-разработчик Redmadrobot
Основная задача, которую я ставил перед собой — общение с гуглерами и GDE. Мне было интересно, как с точки зрения инженеров Google правильно решать те или иные задачи и сравнить их мнение с нашим видением подхода. К примеру, мы с инженерами Google пришли к консенсусу по архитектуре Android приложений — для больших приложений нужно использовать Clean Architecture с MVP / MVVM и роутингом. К сожалению, Ben Weiss и Florina Muntenescu не знали ни про Moxy ни про Cicerone, но мы исправили это досадное недоразумение ;)

Огромное внимание Google уделяет вычислениям в облаке и Firebase — данный технологический стек промелькнул в значительной части докладов и кодлабов. Кроме активного промоутинга Firebase предоставляется и отличная поддержка. Если у вас есть какие-либо вопросы по этому стеку технологий, смело пишите их в релевантный канал Firebase Community on Slack . Если вы не получили ответа в канале, то можете задавать вопросы даже в личку к GDE и инженерам Google

В целом инженеры Google и GDE оказались очень коммуникабельными и доброжелательными ребятами, которые используют Clean, Rx, Dagger, Kotlin и пьют смузи!




Кулаков Артем (@Fi5t), ведущий Android-разработчик Redmadrobot

Я давно интересуюсь темой IoT и Android Things, поэтому на конференции ходил на доклады по этой теме. Из докладов стало ясно, что Google продолжает развивать платформу Android Things и сопутствующую инфраструктуру для нее. Подобные шаги положительно влияют на снижение порога вхождения в тему разработки устройств на базе микроконтроллеров. Приятным сюрпризом стала коробочка с NXP Pico Pro Maket Kit, которую получили участники конференции. Этот жест, вдохновил людей не касавшихся мира железа попробовать себя в этой области.

Отдельно стоит отметить ML направление компании. Как говорили на Google I/O 2017 — компания взяла курс AI-first и призывает других делать так же. Призывы подкрепляются соответствующими инструментами, которые предназначены для разработчиков и аналитиков. Помимо уже привычного Tensorflow и Cloud ML API (Vision, NLP и т.д.), я узнал о существовании курса Machine Learning Nanodegree на Udacity, в котором используется Tensorflow. Конференция показала текущий уровень интереса к ML со стороны сообщества. Больше всего людей я видел как раз возле стенда, где гуглеры отвечали на вопросы по ML.

Ну и вишенкой на торте, лично для меня, стала презентация ARCore. Достойный ответ «некоторой другой компании» и ее ARKit ;) Приятно, что это теперь работает не на одном определенном устройстве как раньше, а на вполне себе обычных Pixel&Nexus. Для неискушенных в графическом моделировании представили набор инструментов Blocks, который помогает создавать 3D модели. Искушенным же предложили rendering engine Rajawali, а для полных джедаев оставили сырой OpenGL ES.





Тимошилов Дмитрий (@HellBurund), ведущий Android-разработчик Redmadrobot

Sundar Pichai считает, что в ближайшие годы Mobile-first сменится на AI-fst. Google Assistant, персональный помощник, – один из ключевых продуктов Google в этом направлении. Он был представлен на Google I/O 2017, и сейчас видно, что Assistant активно развивается. Во время демонстрации Google Assistant выглядел потрясающе. Разработчики идут к тому, чтобы с устройством можно было говорить так же, как с человеком: длинными или короткими фразами, не подбирая слова, вести полноценную беседу. Сейчас уже корректно обрабатываются длинные разговорные фразы типа:

“can you please tell me how is the weather going to be tomorrow in Krakow”

При этом Assistant учитывает контекст разговора. Например, если спросить:

“tell me about Spartak football team”

Assistant расскажет про команду и её игроков. Чтобы узнать какие-то подробности, не нужно опять упоминать Спартак. Достаточно спросить:

“what is the stadium”

и помощник расскажет про Открытие Арену, стадион команды.

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

При этом Assistant встраивается в приложения. Если сказать:

“OK Google, talk to...”

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

К сожалению, Assistant пока не поддерживает русский язык. Но, как удалось узнать у гуглеров, поддержка планируется. Можно надеяться, что появится она в течение года.

Ещё одна из громких тем Google I/O 2017 – Instant Apps, приложения, запускаемые сразу из Google Play, без установки на устройство. Долгое время технология находилась в закрытой бете, но теперь гуглеры готовы рассказывать подробности.
Суть технологии в том, что, когда пользователь хочет воспользоваться какой-то функцией приложения, оно не загружается и не устанавливается на устройство целиком. Google Play загружает тот модуль, который содержит новую функцию, и это происходит быстрее.

Главное, что должно измениться – на смену монолитному apk файлу приходит zip архив, содержащий несколько apk: один базовый и по одному на каждую фичу. Для этого приложение придётся разбить на модули по фичам.
Тут есть важное ограничение. Суммарный объем базового apk и любого из apk с фичами не должен превышать 4 MB. Например, если размер базового apk 3 MB, то остальные должны быть не больше 1 MB каждый.

Про Instant Apps остались открытые вопросы. Как подружить такую архитектуру с Dagger? Насколько комфортно пользователю будет переходить из функционала уже загруженного модуля в функционал ещё не загруженного? Как совместить модульность Instant Apps с модульностью Clean Architecture?
Подробнее про реализацию Instant Apps здесь.

В целом конференция была отлично организована и каждый участник мог найти для себя что-то интересное. Каждый участник получил в подарок IoT набор.

Original source: habrahabr.ru (comments, light).

30 сентября в Питере ожидается два события. Будет солнце и пройдёт первая конференция по технологиям Google для разработчиков — DevFest North. Для одного дня это просто комбо.
Организаторами DevFest North стали Google Developers Groups двух северных городов, Санкт-Петербурга и Петрозаводска. Поэтому конференцию назвали DevFest North 2017.

DevFest — это о чём?

Это серия IT-конференций для разработчиков. Проводится по всему миру и организуется сообществом Google Developer Groups.

Что такое Google Developer Groups?

Это некоммерческое IT- сообщество, в основе которого лежат технологии Google для разработчиков — под Android, Maps, App Engine, Chrome, Web Toolkit, Google Plus и другие.

Что ожидать от DevFest North?

Слово организаторам:

• Мы намерены собрать лучших разработчиков северо-запада на площадке в Санкт-Петербурге.
• Мы делаем DevFest впервые, поэтому мы приглашаем лучших спикеров из Европы и России!
• Мы делаем 2 трека докладов, чтобы вы могли выбрать самое полезное для себя!
• Мы делаем afterparty, чтобы вы могли пообщаться с экспертами и друг с другом в неформальной атмосфере, задать вопросы, которые не успели задать во время сессии, да и просто отдохнуть в компании своих людей.

Мы думаем, что у вас уже достаточно поводов, чтобы купить билет на DevFest North. Вы получите море вдохновения для создания своих интересных проектов после этого дня в компании кодеров, хакеров, вундеркиндов и просто экспертов в IT-отрасли.

ВНИМАНИЕ

Мы любим Хабр и хабражителей, поэтому дарим вам скидку на билет. Возьмите этот промокод DevFest2017Promo и вперёд за билетами по Early Bird стоимости! Вводить код нужно ЗДЕСЬ.

Место проведения:

Конгрессный Центр «ПетроКонгресс» в историческом центре Санкт-Петербурга, Лодейнопольская ул, д.5

Связь:

Задайте любой вопрос организаторам (они любят, когда с ними разговаривают): devfestnorth@gmail.com

А теперь, ОСТОРОЖНО.

Длинный и подробный обзор докладов.

Нам нечего от вас скрывать:

• Bob Van Luijt Google Developer Expert

Amsterdam, Netherlands
Creative Technologist, Kubrickology
Боб — творческий технолог и дизайнер, который работает на пересечении технологий, дизайна и искусства.

О докладе:
A Semantic Internet of Things
Таинственный Интернет вещей — как он помогает нам создать базу знаний, чтобы понять окружение? Как социальные сети, облако или графические базы знаний могут помочь расширить наши познания о мире? Как технологии могут влиять на чувственное восприятие пользователя? “Я хочу показать, что делает творческий технолог, почему я считаю, что творческие аспекты важны в программном обеспечении и над чем я сейчас работаю.”

• Royi Benyossef Google Developer Expert

Samsung NEXT.
Tel-Aviv, Israel

О докладе
Don't use it or you'll lose it!
“Люблю Россию, Android и публичные выступления! В докладе мы рассмотрим некоторые аспекты UX. Я покажу как можно использовать возможности вашего устройства (в том числе, его сенсоров) и некоторые приемы UX для того, чтобы улучшить производительность и удобство использования вашего приложения.”

• Тимур Ахметгареев GDG Москва

Android Lead, App in the Air Inc, Москва, Россия
В разработке более 4х лет, два из них — руководство созданием travel-приложения App in the Air под Android. Среди достижений — звание Top Developer, мировой фичеринг, категория “Лучшее из России”. Были в числе первых, кто выпустил Android Wear приложения. Также имеется уникальный опыт работы с Firebase — моя команда участвовала в бета-тестировании и про наши результаты рассказывали на Google I/O.

О докладе
На DF North Тимур заявил доклад Firebase Alpha tool
Но подробности пока оставил в тайне. Единственное, что мы знаем это: “Одно из решений Firebase должно стать общедоступным к моменту DF North, поэтому я смогу поделиться информацией об этом инструменте на вашей конференции”.

• Михаил Вайсман GDG Москва

CEO Trinity Digital
Михаил, страстный фанат технологий VR. Помимо руководства студией мобильной разработки активно изучает технологии распознавания и искусственный интеллект. Доклад Миши будет посвящен Tensorflow, точнее “Tensorflow: how to cook a working app for 30 minutes”

О докладе
Tensorflow: how to cook a working app for 30 minutes
Создать готовое мобильное приложение с нуля за 30 минут? Легко! Добавить key-value фичи в проект в короткие сроки без штата программистов? Супер просто! Нужны только инструменты машинного обучения, руки и немного магии.

• Константин Цховребов GDG Санкт-Петербург

Senior Team Leader Android, RedMadRobot

О докладе
Toothpick: наше спасение от Dagger 2
Я покажу как опять полюбить DI и как настроить зависимости в приложении легко, красиво и правильно вместе с Toothpick. Пожалуюсь на боль от Dagger 2. И покажу как мигрировать на светлую сторону!

• Артур Василов GDG Санкт-Петербург

Android Developer, Yandex
Один из лидеров GDG SPB
«Сейчас работаю над поисковым Android-приложением Яндекса. Долгое время занимался вопросами архитектуры приложений, выпустил большой и полностью открытый курс по архитектуре Android-приложений. Сейчас же, в первую очередь интересуют вопросы производительности и разработки хорошего UI и взаимодействия с пользователем.»

О докладе
Рецепты анимаций в Android
Как найти идеальный баланс между фантазией дизайнеров и симпатией пользователей при создании анимации в Android? Как выбрать правильный инструмент и когда стоит его использовать, а когда — нет? Понятно и интересно в докладе “Рецепты анимаций в Android”.

• Оксана Покровская и Андрей Хитрый GDG Петрозаводск

Эти ребята — лидеры GDG Петрозаводска и они разработали одну крутую игрушку. Но обо всём по порядку:

Оксана Покровская, Android — разработчик Trinity Digital
«В разработке всего пару лет, сперва была просто Java, теперь Android. Затрудняюсь выделить основную направленность моих интересов — предметная область не важна, главное чтобы была достаточно увлекательная техническая задача, в которой можно по ходу дела поизучать новое.»

Андрей Хитрый, Android-разработчик и тимлид Trinity Digital.
«Начинал с реверс-инжиниринга игр в 2006 и ковыряния линуксов в 2008. Сейчас занимаюсь разработкой под Android и Ruby on Rails. Посматриваю на Go и Angular. Люблю данные. Не люблю горячий кофе.»

О докладе
Firebase Iot Game
«Наш проект — уникальная настольная игра с “умными” компонентами. Собрана она из Firebase, Android, NFC меток, ESP 8266, RFID-RC522. Мы не только расскажем про особенности работы с Firebase с разных устройств и Firebase-функции, но и покажем, как эта игра работает.»

• Александр Денисов GDG Нижний Новгород

Лидер GDG Нижний Новгород
Lead Software Engineer в NetCracker
Александр — специалист по бизнес логике и базам данных, профессионально занимается разработкой больше 10 лет, раньше работал с С++ и С#, но последние несколько лет перешел на Java.

О докладе
Firebase Cloud Functions: New opportunities of serverless backend.
Думаете, что отлично знакомы с Firebase Cloud Functions? Тогда будьте готовы удивляться. Александр Денисов расскажет не только о классической работе с Cloud Functions, но и о их взаимодействии с множеством других инструментов и ресурсов.

• Алексей Буздин GDG Riga

Riga, Latbia
Алексей — опытный разработчик и тренер. Обожает обсуждать ИТ и технику. Лидер Google Developer Group Riga.

О докладе
Writing a Plugin for Android Studio
Доклад Алексея будет посвящен написанию плагина для IntelliJ Idea или Android Studio. “Давайте рассмотрим, как мы можем сделать собственный плагин для нашего любимого инструмента!”

• Сергей Рябов

Москва
Android Engineer, Independent

О докладе
Use the Force (of Kotlin Stdlib).
Сергей — независимый Android разработчик с опытом в backend. Был первым, кто внедрил в работу язык Kotlin. Называет себя Rx зависимым. Угадайте, чему будет посвящен его доклад? Конечно — Kotlin и называться он будет Use the Force (of Kotlin Stdlib).

• Bogdan Mukvich

Москва
Старший инженер по автоматизации QA в Tinkoff bank

О докладе
Путь автоматизации Android
Доклад Богдана будет называться «Путь автоматизации Android». Вас ждёт разговор о перспективах автоматизации, опыте и будущем.

Расписание докладов смело можно смотреть по ссылке

Увидимся на DevFest North в Питере 30 сентября!

Original source: habrahabr.ru (comments, light).

Меня зовут Полина, и у нас с мужем своя онлайн-школа программирования для детей. Учим ребят от 8 до 16 лет по всему миру через Skype. Захотелось поделиться своим опытом и наблюдениями в данной сфере.

Почему мы перешли на онлайн-занятия

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

1) Когда в одной комнате собирается даже 5-6 учеников, очень сложно поддерживать качество обучения на высоком уровне. Дети часто отвлекаются, мешают друг другу, балуются. Преподавателю приходится тратить очень много времени, чтобы успокоить и настроить учеников на работу. Это совсем не эффективно.

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

3) Достаточно часто возникали проблемы с компьютерами. То дети воду разольют на клавиатуру, то удалят что-нибудь, сломают, ноутбуки тормозят и т.д. Сразу же начинается шум: «Ааа, у меня комп сломался!» И учитель превращается в системного администратора. Отнимает много времени и нервов.

4) Если вы думаете, что такие очные занятия учат работать детей в команде, то это не так. В силу того, что у детей разный уровень, один из команды будет делать, а остальные ковырять в носу. Программирование – интровертный процесс, нужно погрузиться в проблему, чтобы решить задачу. Развивать soft skills и программировать одновременно невозможно. Это разные виды деятельности, и развивать их нужно по отдельности. Можно учить ребят делить большой проект между собой, чтобы потом они могли части своего кода сгруппировать вместе. Но работают они над своим куском отдельно.

5) Родителям нужно привозить и забирать ребенка. И во время занятия тоже не понятно куда себя деть, не всегда успеешь съездить по делам. Многие родители сидели у нас в коридоре 2 часа, ждали пока закончится занятие.

Один из знакомых родителей, чей сын ходил в одну крупную IT-школу рассказал нам такую историю:

«Моему сыну 9 лет, он сейчас пошел в 3-й класс гимназии и параллельно занимается на IT-курсах для детей. Впечатления сложные, скорее, негативные. Там слабо следят за тем, что делают дети за компьютерами. Пока учитель читает лекцию, некоторые ребята умудряются переписать на компьютер с принесенной флэшки Counter-Strike и подначивать соседей по классу поиграть с ними. Ребенку не хватает нормального общения со сверстниками, т.к. нужно завязывать новые отношения. Он тянется к ребятам, прогибается под них и не всегда, к сожалению, ищет общения с примерными одноклассниками. Так и там получилось. Например, один раз его сосед открыл во время лекции на своем компьютере google images и стал искать там фотографии, простите, говна. А мой сын громко смеялся над этими фотографиями, за что его в конце концов и наказали двойкой, настоящего зачинщика при этом не обнаружив. Кроме того, в отличие от гимназии, где ребята в основном хорошие и круг общения в основном складывается из сверстников, на курсах контингент очень разнообразный, и по возрасту, и по воспитанию. В результате общения с разными ребятами у сына на телефоне появляются такие приложения, за которые должно быть стыдно, и которые приходится вычищать, объясняя, почему это гадость. Мы обращались в учебный отдел, нам ответили, мол, учитель физически не может ни видеть, что на каждом экране, ни блокировать компьютеры. Ещё один момент был: если сын что-то где-то не успевал, он стеснялся сразу уточнить задание или попросить помощи у учителя, а потом было уже слишком поздно. Ему явно больше подойдет индивидуальное обучение».

Переход на онлайн

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

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

Какие плюсы мы выявили:

• Преподаватель выдает индивидуальное задание, подбирая по желанию и способностям. Ребенок занимается в своем темпе, ни на кого не отвлекается.
• Все занятие преподаватель видит экран ученика, может сразу же ему подсказать, помочь.
• Никаких проблем с дисциплиной. Ребенок чувствует, что за ним все время наблюдают, поэтому стесняется даже лишний раз переключиться на «левую» вкладку в браузере.
• Ребенок может петь себе под нос, бубнить, рассуждать, и никто не будет смеяться или «затыкать» его.
• Ребенку не надо стесняться. Он может легко спросить обо всем. Может попросить дать задание посложнее или легче, или на другую тему. Сам выбирать чем заниматься именно сегодня.
• Родителям не нужно никуда ездить, посадил дома за компьютером и все. Если хочешь, можешь посидеть рядом и понаблюдать, как проходит занятие.
• Можно заниматься из любой точки мира и не прерывать занятия: на отдыхе с родителями, переехали в другую страну, у бабушки на даче. В общем, везде, где есть интернет.
• Или наоборот, можно закончить и возобновить занятия в любой момент. Ведь ребенок занимается по своей программе, и ему не придется ничего «нагонять».

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

Онлайн занятия ведем больше года, учится уже больше 100 учеников по всему миру.
Мы учим ребят программировать на Scratch, Python и JavaScript. Плюс есть занятия по Photoshop, 3D-моделированию и информационной безопасности.

Иногда прямо сами завидуем, что у нас в детстве такого не было. Например, у нас есть ученик мальчик Эрол, уже в 12 лет копается в клиент-серверных приложениях, сокетах. Хотя начинал со Scratch, потом перешел быстро на Python. Если бы он занимался в классе, то не достиг и не попробовал бы и половины из этого. А так тренер видит и чувствует, что Эрол быстро схватывает, очень усердный, ему самому нравится копаться, и дает все сложнее и сложнее задания.

Если сейчас формат онлайн-занятий еще для многих в новинку, то через лет 5, я уверена, это будет нормой.

Original source: habrahabr.ru (comments, light).

По мере роста вашей компании вы несомненно будете испытывать дефицит ресурсов и времени.

Хотите сделать больше операций с меньшими затратами, но не знаете, с чего начать?

Вот 5 простых рекомендаций по автоматизации наиболее часто повторяющихся элементов вашего процесса продаж с помощью CRM-системы. Автоматизация наиболее часто повторяющихся и рутинных операций позволяет высвободить время менеджеров для заключения сложных сделок и сосредоточиться на функциях, требующих большей квалификации.
/habrastorage.org/web/c7f/d01/07c/c7fd0107cb8445f9a898127d002b64ee.jpg">" alt=«image»/>
1. Ваши лиды (Leads), ваши правила. [распределение лидов (Leads) между менеджерами]

Без правильной автоматизации вы должны вручную назначить каждому новому лиду конкретного менеджера по продажам. Если вы получаете 100 лидов каждый день, это означает, что вы будете выполнять ту же задачу 100 раз! Допустим, вы тратите 3-4 минуты на распределение лида, получается, что на обработку всех лидов вы тратите минимум 350 минут в день (около 6 часов). То есть, как минимум, нужно выделить 1 человека на распределение запросов от потенциальных клиентов.

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

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

Вы сами можете с помощью Flexbby Sales настраивать интеллектуальные правила распределения запросов на основе квалификационной анкеты.

Как показывает практика только 20% клиентов приносит 80% денег. Если правило Парето применить 2 раза, то 4% клиентов будет приносить 64% выручки. Задумайтесь только 4% усилий продавцов приносит более 60% выручки.

2. Прекратите усложнять, занимайтесь бизнесом. [приветственные письма]

Отправка 100 писем по новым лидам означает, что нужно составить эти 100 писем. Но если нужно просто скопировать и вставить тот же текст и меняется только имя получателя, зачем одно и тоже делать 100 раз? Вы не создаете ничего нового — это просто повторение, дублирование и клонирование содержимого. Приложение Flexbby Sales освобождает вас от подобной чисто механической работы. Создайте шаблоны писем для ускорения процесса, и вы сможете привлечь еще 100 лидов в высвободившееся время. Создайте правило, по которому система автоматически будет высылать новому адресату (лиду) приветственное письмо определенного содержания. Так же Вы можете настроить цепочки писем, которые автоматически отправляет система по определенным правилам в зависимости от данных в квалификационных анкетах. Эти правила вы можете определять и настраивать самостоятельно, анализировать, какие цепочки писем дают максимальный результат.

3. Понимайте с полуслова. [развитие отношений с новым клиентом]

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

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

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

4. Больше сделок, меньше времени [согласование условий сделки]

Если Вы не автоматизируете обработку запросов на скидку или заказы на покупку, сделки могут не состоятся, потому что информация оперативно не доходит до ваших менеджеров. По крайней мере три этапа в обработке запросов: создание задания, отправка менеджеру, ожидание в получении одобрения сделки. Но если вам надо закрыть сделку, зачем вам эти действия? Вам нужно встроить в процесс вашей сделки этап согласования, который будет возникать автоматически в зависимости от условий. Если условия не возникли, то этот этап будет пропущен. Система Flexbby позволяет добавлять этапы сделок динамически в зависимости от условий. Например, в какой-то момент условия сделки не требовали согласования, и она двигалась по определённому процессу, затем изменилась стоимость контракта или существенно изменились условия по предоплате, и это уже требует согласования вышестоящего руководства. Интеллектуальные обработчики Flexbby добавят или удалят согласователей, переведут сделку в нужный этап. Чем меньше ручных операций, тем меньше человеческих ошибок, тем меньше узких мест в процессах и эффективнее бизнес. Автоматизируя любой процесс, всегда помните: 4% усилий — 60% результата. Задача руководителя и системы автоматизации — научиться выделять эти 4% и не делать 96% работы, которые не приносят результата.

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

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

5. Будьте проактивными. [эскалация]

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

Например, во время квалификации можно сегментировать клиентов по категориям A, B, C, D.

Для категории A – настроить задачи персонального общения менеджера по продажам с клиентом – это те 4% клиентов, которые делают основной бизнес, и эти сделки терять ни как нельзя.

Для категории B – настроить автоматические письма и незначительное количество задач для персонального общения менеджерам.

Для категории C – настроить только автоматические письма.

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

BE FLEXBBY!

Original source: habrahabr.ru (comments, light).