Разбираемся, где доступно почитать и пощупать, что машины могут в дизайне (и что читать до этого).

Мечтают ли роботы об электроовцах «Заменят ли роботы веб-дизайнеров?» — таким вопросом я на секунду задался, узнав, что мы учимся делать новые сайты из старых — с нейросетями и такой-то матерью. Понимание «Конечно, нет» пришло довольно быстро — почему, мы говорили в прошлой статье с Джоном Голдом.

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

Предыстория гуманитария

Сам список

Интерес к теме «машина, сделай за меня» прорезался в начале 2000-х. Старший брат Voldar притащил откуда-то диск, сказал «Ща все будет» — и весь вечер возился с настройками микрофона. Короче, запустить систему распознавания речи в текст у нас тогда так и не получилось.

Зато сегодня по работе я использую на ноутбуке расширения вроде Speechpad, чтобы надиктовать «скелет» текста — в том числе этого. Правда, надо искусственно замедлять себя и вообще стараться говорить так, будто ты Левитан.

Поэтому скепсис к теме был.

Предыстория. «Что значит быть летучей мышью?» — Томас Нагель, 1974

А зародился этот скепсис в 2009-м. И дело в этой маленькой брошюрке, которую нам дали на курсе философии. Если кратко, то это статья о том, что «чужая душа — потемки». Нагель очень здорово объясняет, почему люди не понимают друг друга: так что если сталкиваетесь по работе или в жизни, почитайте, — поможет впадать в дзен в такие моменты.

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

Все объяснение строится на попытке человека понять, как устроено сознание летучей мыши: да, можно висеть головой вниз, зажмуриваться и бегать по офису, махая руками… Можно даже дождаться момента, когда британские ученые смогут сделать из вас оборотня. Но! В голове мыши по-прежнему есть «черный ящик» — и сможем ли мы докопаться до его сути, большой вопрос. Вот к такому выводу приходит автор.

Эти несколько страниц размышлений о том, можем ли мы понять свое или чужое сознание, можно назвать и «одой против ИИ». Во-первых, мысль «если мы не можем понять маленькую тварь, которая полдня висит вниз головой, то куда уж до чего-то большего» прослеживается довольно четко. А во-вторых, статья появилась накануне «AI winter» — периода в середине 1970-х, когда расходы на разработки в этой сфере резко сокращали.

С такими сомнениями я и пошел в чат. И вот что получилось.

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

1. «Об интеллекте» — Джефф Хокинс, Сандра Блейксли, 2004

(рекомендует pavel_kudinov)

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

С 2007-го доступен перевод книги на русский, он выдержал уже несколько изданий. Заказать можно практически в любом онлайн-книжном.

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

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

Книжку критикуют за излишнюю популярность и минимальное представление мнений оппонентов. Но для гуманитария самое то. Поэтому Павел, CTO нашего проекта, кидается ей во всех.

2. «Машинное обучение для дизайнеров» — Патрик Хеврон, 2016

(рекомендует lyubim)

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

Издательство O’Reilly вовремя заметило появление новых AI/ML-инструментов для дизайнеров, нашло эксперта и практика (Хеврон занят созданием дизайн-инструмента Foil, использующего машинное обучение) — и выпустило с ним бесплатную книжку.

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

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

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

3. uKit.ai – блог нашей команды о генеративном дизайне

(рекомендует Kurt)

Здесь выходят переводы интересных зарубежных статей на тему применения нейросетей в веб-дизайне и смежные темы.

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

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

4. Algorithms.design — Юрий Ветров

(рекомендует alexahdp)

Юрий — «руководитель дизайн-команды портальных сервисов Mail.ru”, а также евангелист всего, что связано с дизайном при участии машин, ведет свою англоязычную подборку ссылок на интересные инструменты и полезные статьи по теме.

Сейчас на сайте 5 категорий: “Создание интерфейса”, “Подготовка контента”, “Персонализация пользовательского опыта”, “Графический дизайн”, “Другое”.

Удобно — все разложено по полочкам. Посетители могут дополнять подборки, присылая Ветрову ссылки на свои или понравившиеся проекты. Краудсорсинг в действии!

5. Deephunt.in – Авинаш Гиндупур

(рекомендует RomanSt )

Еще один евангелист ИИ, но в более широком плане, Гиндупур выпускает на своем сайте регулярные дайджесты «что случилось в мире AI”. А с недавнего времени стал делать и подборки. Подборки (точнее, подборка, но мы надеемся на появление новых) хороши особенно.

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

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

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

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

***

P.S. Спасибо, если вам было полезно. Отдельное спасибо, если вы поделитесь своими источниками информации об алгоритмическом (генеративном) дизайне для сочувствующих — мы включим их в подборку с указанием автора, рекомендовавшего ресурс или книгу.
ссылка на оригинал статьи https://habrahabr.ru/post/329916/

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

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

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

Как сравнивать

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

Дополнительные «плюшки» в комплекте уличных камер обычно не предусмотрены – карта памяти/кабель питания идут вместе с «домашними» Nobelic/Oco2. Внешний вид камер стандартен для этого класса. Подключение идентичное (за одним исключением).|

Остается практически единственный критерий (кроме цены) – качество изображения.

Модели для теста

Nobelic NBLC-3130F-WSD с Wi-Fi

Самая простая и доступная уличная камера за 6 700 руб. За такую цену владельцы маленьких магазинов могут получить готовое решение для безопасности, контролирующее достаточно большую территорию.

Можно использовать не только на улице, но и внутри помещений. Угол обзора 72°, защита от влаги и пыли по стандарту IP67. К интернету подключается как по Wi-Fi, так и через Ethernet.
Рабочая температура: от -30 до +50 градусов Цельсия – выживет на европейской территории России.

Размеры камеры не привлекают лишнее внимание: 70 × 165 мм.

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

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

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

Nobelic NBLC-3430F

Компактная, мощная 4-х мегапиксельная уличная камера, габаритами похожа на предыдущую модель (70×165 мм). Корпус камеры защищен по стандарту IP67. Рабочая температура от -30 до +60 градусов Цельсия. ИК-подсветка до 30 метров – камера захватит большой участок территории даже ночью, когда сторож уже глубоко спит.

Камеру можно запитать от PoE (по витой паре) и от блока питания 12 вольт – наличие выбора дает дополнительное преимущества: меньше возни с монтажем, и камеру легче переставить.

Разрешение в два раза выше, чем у Nobelic 3130F, угол обзора также больше, но выросла и цена – до 11 990 руб. За эти деньги вы должны получить решение, которое не захочется поменять через несколько лет. Не будем забывать, что камера – это не убыток для предприятия, а инструмент по добыванию денег. Будет странно, если камера через некоторое время покажется устаревшей, не сможет выполнять свои функции, и, следовательно, приносить прибыль. Проверим этот тезис дальше, на этапе тестирования.

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

Nobelic NBLC-2430F с защитой от вандалов

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

В 4 Мп модель 2430F встроено несколько технологий шумоподавления, а также реализована технология широкого динамического диапазона, позволяющая получить нормальное изображение в условиях резких перепадов освещенности.

Камеру можно запитать от PoE (по витой паре) и от блока питания 12 вольт.

Выдерживает температуру от -30 до +60 градусов Цельсия; отличается чуть менее скромными размерами – 110 × 81 мм. Но больше камера – и становится больше угол обзора: 106°.

Nobelic NBLC-3230V-SD с вариофокальным объективом

Варифокальный объектив позволяет вручную или автоматически корректировать фокусное расстояние, тем самым изменяя углы обзора (99-37°) и масштаб выбранной области просмотра. Это позволяет вам через облачный интерфейс смотреть на разные объекты. Не нужно ехать за 100 километров к камере, чтобы изменить фокус и посмотреть, как разгружается фура, которая решила припарковаться в укромном месте.

У камеры есть слот для карты памяти, так что вы можете включить локальную запись видео на карточку Micro SD.

Nobelic 3230V-SD поддерживает питание по витой паре, а также ее можно запитать от блока питания 12 вольт.

Размеры камеры: 90,4 × 213 мм. Переживет суровые условия: от минус 40 градусов до плюс 60.
Цена на камеру составляет 15 490 руб – максимальная отметка в обзоре, достигнутая за счет объектива и надежности. Оправданна эта сумма или нет – проверим на тесте.

Таблица основных характеристик

Поддерживаемые протоколы: IPv4/IPv6, HTTP, HTTPS, TCP/IP, UDP, UPnP, ICMP, IGMP, RTSP, RTP, SMTP, NTP, DHCP, DNS, PPPOE, DDNS, FTP, IP Filter, QoS.

Поддержка протокола ONVIF появится позже, сейчас в разработке.

Сравниваем качество изображений

Nobelic NBLC-3130F: угол обзора 72° (горизонтальный), разрешение матрицы 1280×960.

Nobelic NBLC-3430F с 4 Мп 1/3«CMOS матрицей, снимающей видео с высоким разрешением 2688х1520. Угол обзора 84°.

Nobelic NBLC-2430F с 4 Мп 1/3” CMOS матрицей, разрешение 2688×1520. Широкий угол обзора 106°.

Nobelic 3230V-SD оборудован 2 Мп 1/3»CMOS матрицей, снимающей видео в разрешении 1920х1080. Угол обзора изменяется: по горизонтали 99°-37°, по вертикали 52° — 21°.

Сравнение сразу всех камер на расстоянии 8 метров с 8-кратным приближением.

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

Больше различий между камерами становится заметно на расстоянии 15 метров. Мы приблизили картинку в 12 раз. Nobelic 3230V показал результат чуть хуже – мы не стали вручную менять фокус, записывая лишь автоматические результаты. Тот случай, когда нужно заглянуть в интерфейс и подправить камеру, благо через интернет это можно сделать даже через телефон.

Оригинальная картинка с четырех камер. Единственная камера из обзора, которая дает четкое изображение дальше 18 метров – это Nobelic 3430F.

Выводы

Относительно низкая цена не всегда означает, что камера сильно проигрывает в качестве изображения – Nobelic 3130F стоит меньше остальных, однако здорово держится на всей тестовой дистанции. Эту камеру можем советовать владельцам небольших компаний, которые хотят за ограниченный бюджет получить максимум возможностей.

На другой стороне шкалы возможностей оказывается Nobelic NBLC-3430F – камера выигрывает за счет высокого разрешения 2688х1520 и доказывает, что не всегда количество мегапикселей имеет решающее (либо равноценное) значение. Камера подходит для наблюдения за большими открытыми пространствами.

Лишь ненамного отстаёт купольная камера Nobelic NBLC-2430F – разрешение у нее такое же, как у 3430F, а вот угол обзор шире. За счет этого объекты, расположенные по центру изображения, кажутся чуть менее четкими. Зато в кадр помещается больше деталей.

Особняком стоит камера Nobelic 3230V-SD. При всех заявленных характеристиках камера требовательна к пользователю. Требует настройки под конкретный вариант применения, но сделать это можно без особого труда.
ссылка на оригинал статьи https://geektimes.ru/post/289707/

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

Андрей Сатарин занимается тестированием распределенных систем в Яндексе. Принимал участие в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, а также систему расчета валютных цен в Deutsche Bank.

— Отказоустойчивость — одно из важнейших нефункциональных требований к распределенным системам. Как проводится тестирование отказоустойчивости?

Андрей Сатарин: Сбои можно эмулировать в тестовой среде, так работает известный инструмент Jepsen, созданный Кайлом Кингсбери (Kyle Kingsbury). Второй подход предполагает внедрение сбоев в продуктивном окружении и обычно ассоциируется с Chaos Monkey компании Netflix, из которого выросло целое движение — хаос-инжиниринг. Он избавляет нас от проблем с повторением продуктовой среды и дает высокую уверенность в работоспособности системы, но более опасен и требует определенной зрелости продукта.

Есть и третий подход, позволяющий проверить работоспособность алгоритмов еще до написания кода с помощью специальных инструментов, таких, например, как TLA+. Два наиболее известных примера его использования: разработка Amazon Web Services и Azure Cosmos DB.

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

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

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

— Каковы наиболее распространенные ошибки при тестировании отказоустойчивости распределенных систем?

Андрей Сатарин: На мой взгляд, самая главная ошибка — непонимание системы. Нужно четко себе представлять, что система делает, какие в ней есть ограничения и как мы их тестируем. Если у нас, например, есть требования по аптайму, то как их проверять в случае сбоев?

Даже не приводящая к потере данных мелкая проблема может нарушить нам SLA. Нужно понимать, какие сбои будут происходить в реальности, потому что потенциально их можно внедрить огромное множество, но к определенным классам сбоев ваша система может быть не готова by design — следует отделять одно от другого и не пытаться тестировать систему в ситуациях, в которых она в принципе не должна работать.

— Какие есть основные методики проверки производительности распределенной системы? Какие здесь есть тонкости, подводные камни, какие ошибки допускают при тестировании?

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

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

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

— Какие еще есть нюансы при тестировании выполнения нефункциональных требований?

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

Еще один важный момент — тестирование конфигурации системы. Ваш код может работать прекрасно, но в сложной распределенной системе много конфигурационных параметров и неправильная их настройка может привести к падению производительности, например, или даже к потере данных. Хороший пример такой ситуации рассмотрен в статье Paxos Made Live — An Engineering Perspective. Речь в ней идет о ситуации с Google Chubby, когда сконфигурированный для работы на пяти узлах кластер работал на четырех. Благодаря изначально заложенной в систему отказоустойчивости сервис функционировал, но уже не мог выдержать потерю двух узлов.

— Насколько важна производительность самих тестов и как её можно повысить?

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

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

— Есть какие-то инструменты для автоматизации тестирования нефункциональных параметров распределенных систем?

Андрей Сатарин: Есть известный инструмент Jepsen, который применяется для достаточно широкого класса различных систем: Apache Cassandra, MongoDB и т. д. К сожалению, его нельзя просто запустить из коробки — придется программировать. Имеющиеся инструменты нужно затачивать под тестируемую систему и порог входа у них достаточно высокий. Если говорить о производительности, существуют разнообразные бенчмарки, такие, например, как Yahoo Cloud Server Benchmark, который проверяет различные хранилища, вроде уже упомянутых Cassandra и MongoDB.

— Какие проблемы в сфере тестирования распределенных систем пока остаются нерешенными? Расскажите об основных тенденциях развития этого направления.

Андрей Сатарин: Эта область становится более зрелой, многие компании начинают использовать сложные тесты типа Jepsen  для внедрения сбоев с проверкой уровня консистентности своих систем. В последнее время активно применяются формальные методы, о которых я уже говорил — TLA+ и формальная верификация заложенных в распределенную систему алгоритмов.

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

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

ссылка на оригинал статьи https://habrahabr.ru/post/329974/

Этот пост является вольным переводом статьи Kotlin and Swift. Is it a whole new era in Mobile Development? by Andrew Cherkashyn

Когда в Google объявили о том, что они теперь официально будут использовать Kotlin для разработки под Android, я, как и многие другие Android-разработчики, вздохнул с облегчением. Я еще раз зашел на официальный сайт Kotlin, чтобы перепроверить функционал/синтаксис и сравнить его с последней версией Swift, на котором сейчас пишу, и вдруг ощутил это: проходит одна эпоха и начинается новая, по крайней мере в мобильной разработке…

В Kotlin, как и в Swift довольно много синтаксического сахара, который снижает объемы обычной рутины (сравнение синтаксиса тут: http://nilhcem.com/swift-is-like-kotlin/). Но что меня особенно радует — они оба, прям "из коробки", поддерживают новые парадигмы программирования. Особенно функциональное программирование.

Принципы функционального программирования, конечно, не являются чем-то новым в разработке, даже наоборот. Но теперь, когда есть официальная поддержка "из коробки" в разработке под iOS и Android — стоит пользоваться именно ими.

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

Java:

String[] mixedArray = new String[] { "4", "5", "a", "-2", "Str" }; int results = 0; for (String element : mixedArray) {     results += Integer.parseInt(element); }

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

Kotlin:

val mixedArray = arrayOf("4", "5", "a", "-2", "Str") val results = mixedArray     .filter { obj -> obj.toIntOrNull() != null }     .map { x -> x.toInt() }     .reduce { acc, x -> acc + x }

Swift:

let mixedArray = ["4", "5", "a", "-2", "Str"] let results = mixedArray     .filter({ (obj) -> Bool in return Int(obj) != nil })     .map { (obj) -> Int in return Int(obj)! }     .reduce(0, +)

Блоки были представлены Apple для Objective-C в 2010 году (iOS SDK 4.0), чтобы улучшить жизнь разработчиков и соответствовать анонимным классам в Java, которые могут быть использованы как коллбэки:

Пример блока в Objective-C:

void (^newBlock)(void) = ^{     NSLog(@"New block is called"); };

Пример анонимного класса в Java:

(new CallbackClass() {     @Override public void call() {         Log.i(StaticTag, "Callback is called");     } });

Лямбда-выражения в Java были представлены в 2014, как часть JDK 8, но к сожалению они не были доступны Android-разработчикам, потому что Android SDK поддерживает только JDK версии 7 (поэтому и есть такие библиотеки, как retrolambda: https://github.com/evant/gradle-retrolambda).

Теперь же оба языка полностью поддерживают такой подход: в Swift — "замыкания" (то же самое, что блоки в Objective-C), а у Kotlin есть поддержка "лямбд", которая работает в Android SDK:

Пример замыкания в Swift:

{ _ in     print("Closure is called!") }

Пример лямбды в Kotlin:

{     println("lambda is called!") }

Начиная с Xcode 4, где-то с 2011, Objective-C предоставляет однострочную инициализацию для массивов и словарей:

Пример инициализация в Swift:

let numbersArray = [2, 4, 1] let dictionary = ["key1": "value1", "key2": "value2"

В JDK доступна только статическая инициализация, но нет способа инициализировать Map в одну строку. Функция Map.of которая позволяет это, была представлена только в JDK 9.

Пример статической инициализации в Java:

// Array private static final int[] numbersArray = new int[] {2, 4, 1}; // Map private static final Map<String, String> map; static {     map = new HashMap<String, String>();     map.put("key1", "value1");     map.put("key2", "value2"); }

Но теперь Kotlin умеет делать так:

mapOf<String, String>("key1" to "value1", "key2" to "value2")

Еще одна вещь, которую я хочу выделить — Range операторы, которые делают вашу жизнь намного проще. Теперь вместо использования циклов for для простого обхода:

for (int i = 0; i < N; i++) {     // Do something }

Вы можете делать в Kotlin так:

for (i in 0..N-1) {     // Do something }

Или вот так в Swift:

for i in 0..<N {     // Do Something }

Стоит еще упомянуть о кортежах (tuples). Они дают определенную свободу во взаимодействии с другими компонентами и помогают избегать создания дополнительных классов.

Итак, глядя на все эти новые "фичи" и многие-многие другие вещи, которые не упомянуты в этой статье — я бы предположил, что новая эпоха уже началась. Теперь всем новичкам, которые начинают свой путь в мобильной разработке, будут доступны все эти функции прямо "из коробки", и они смогут сократить затраты на рутинную разработку бизнес-логики и управление приложением. И это намного важнее, чем писать сотни строк для того чтоб сделать простой кусок работы. Конечно, раньше вы могли просто поставить и настроить дополнительную библиотеку, такую как PromiseKit, ReactiveCocoa, RxJava и т.п. Но я верю, что доступность этих парадигм и принципов — будет побуждать новых разработчиков использовать именно их, что приведет нас к светлому будущему. 🙂

Спасибо за внимание! Я надеюсь вам было интересно или, как минимум, это пост дал вам свежие идеи. Я пытался написать коротко, но если вам нужны более конкретные примеры и/или у вас есть предложения/замечания — пожалуйста, напишите в комментариях!

ссылка на оригинал статьи https://habrahabr.ru/post/329870/

Как говорилось во всеми нами любимом фильме: «Налетай, торопись, покупай живопись». Последняя, конечно, тут ни при чем, а вот «налетать» на новую Бета версию компилятора уже пора. Сегодня я расскажу о том, что нового появилось в пакете Intel Parallel Studio XE 2018 Beta, и в частности, в компиляторной её составляющей. А там действительно много что добавилось, ведь стандарты не стоят на месте — C++14, C++17, Fortran 2008, 2015, OpenMP 4.5 и 5.0, а компилятор должен не только их поддерживать, но и генерировать совершенный, производительный и безопасный код. Кроме этого, новые наборы инструкций AVX512, позволяющие «снимать сливки» с последних процессоров Skylake и KNL, всё больше входят в арсенал современных компиляторов. Но а самое вкусное — новые ключи, которые позволяют получить ещё больше производительности «не напрягаясь». Итак, поехали!

Сразу скажу, что качать Beta версию можно здесь:

Intel Parallel Studio XE 2018 Pre-Beta survey

Всё, о чем я буду говорить, включено в эту версию компиляторов и Update 1, который очень скоро будет доступен. Что потом окажется в финальном продукте – вопрос сложный, но, «вангую», почти всё. Что же мы имеем в новой версии 18.0 Beta?

Безопасность кода

В Microsoft изо всех сил стараются противостоять хакерам и придумывают всё новые и новые технологии. Для начала, они сделали в своём компиляторе С++ дефолтным максимальный уровень защиты стэка через опцию /GS:strong, которая позволяет бороться с переполнением буфера. При этом делается это в ущерб производительности, но безопасность превыше всего. Так как Intel под Windows пытается быть полностью совместимым с компилятором от Microsoft, то начиная с новой версии мы тоже включаем /GS:strong по умолчанию. Ограничить её действие и немного улучшить производительность можно с помощью /GS:partial.

Кроме этого, идёт разработка новой технологии CET (Control-Flow Enforcement Technology), позволяющей бороться с атаками методом возвратно-ориентированного программирования (ROP и JOP-атаками). Одна из идей защиты состоит в том, что появляется ещё один защищенный shadow стэк, в который будет записываться/дублироваться адрес возврата. Когда мы доходим до возврата из функции, происходит проверка корректности возвращаемого процедурой адреса и того адреса, который мы положили в shadow стэк. Кроме этого, добавляется новая инструкция ENDBRANCH для того, чтобы обозначать области в программе, на которые можно делать непрямые переходы через call/jmp. Реализован конечный автомат, и как только процессор обрабатывает одну из инструкций call/jmp, он переходит из состояния IDLE в WAIT_FOR_ENDBRANCH. Собственно, в этом состоянии следующая инструкция для выполнения должна быть ENDBRANCH. Гораздо больше деталей написано в указанной выше статье, а в компиляторах Intel для С/С++ и Fortran появилась поддержка CET через опцию -cf-protection. По умолчанию, она не включена и, естественно, может влиять на производительность при использовании.

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

Производительность

Теперь поговорим о новых опциях компиляторов, которые позволят сделать ваши приложения ещё быстрее и производительнее.
Есть такая компиляторная оптимизация, которая называется function splitting (разделение функций). Для того чтобы понять, зачем она нужна, стоить вспомнить про встраивание кода и то, что одним из эффектов является увеличение его размера. Поэтому inlining не имеет смысл при больших размерах самой функции, которую мы хотим встроить в место вызова. Именно в этих случаях разбиение функции и частичный inlining нам поможет не допустить чрезмерного увеличения размера кода, сохранив её плюсы. В итоге наша функция будет разбиваться на две части, одна из которых (hot) будет встроена, а другая (cold) – нет.

На самом деле, эта оптимизация уже долгое время присутствует в 32-битных компиляторах Intel для Windows, при использовании Profile-Guided Optimization (PGO). Вот, кстати, интересный пост про эту оптимизацию в gcc. Идея проста – скомпилировать наше приложение, сделав инструментацию, затем запустить его и собрать данные о том, как оно выполнялось (профиль), и, уже учитывая эти данные из рантайма, пересобрать код ещё раз, применив полученные знания для более мощной оптимизации.

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

Сейчас мы уже позволяем разработчикам контролировать эту оптимизацию «ручками», добавляя ключ -ffnsplit[=n] (Linux) или -Qfnsplit[=n] (Windows), который говорит компилятору, что нужно выполнять разбиение функции с вероятностью выполнения блоков равным n или меньше. При этом не важно, включено PGO или нет, но нам обязательно указывать этот параметр n. Если его не указать, то данная оптимизация будет выполняться только при наличии динамической информации от PGO. Значения n могут быть от 0 до 100, но наиболее интересные для нас находятся в первой половине. Скажем, при PGO и 32 битном компиляторе на Windows использовалось значение 5, означающее, что если вероятность выполнения менее 5%, то этот блок не будет инлайнииться.

Если мы заговорили про PGO, то обязательно стоит сказать, что и здесь в новой версии Студии произошли приятные изменения. Раньше эта оптимизация работала только с инструментацией, но теперь возможна работа с использованием сэмплирования из профилировщика VTune. К реализации такой фичи подтолкнула невозможность применения традиционного PGO на real time и embedded системах, где имеются ограничения на размер данных и кода, а инструментация могла его существенно увеличить. Кроме этого, на подобных системах невозможно выполнять I/O операции. Аппаратное сэмлирование из VTune позволяет существенно снизить накладные расходы при выполнении приложения, при этом не происходит увеличения использования памяти. Этот способ даёт статистические данные (при инструментации они точные), но при этом применим на системах, где традиционный PGO «буксует».

Схему работы с новым режимом PGO можно представить в виде диаграммы:

Как и прежде, нам нужно скомпилировать наш код для последующего сбора статистических данных. Только теперь это делается с помощью опции -prof-gen-sampling (Linux) или /Qprof-gen-samplig (Windows).

На выходе мы получим бинарники с расширенной дебаг информацией (что увеличит размер на допустимые 5-10%), но без инструментации. А далее нам понадобится специальный скрипт из VTune для запуска приложения и генерации профиля. После чего (если не нужно мержить несколько профилей), просто пересобираем наш код с полученными данными с ключиком -prof-use-sampling (Linux) или /Qprof-use-sampling (Windows). Для работы с этими опциями нам понадобится VTune, поэтому нужна установка не только компилятора, но и профилировщика. В Beta пакете имеется и то, и другое.

Теперь поговорим о работе с математическими функциями из библиотеки SVML (Short Vector Math Library), предоставляющей векторные аналоги скалярных математических функций.
Сразу несколько изменений коснулись SVML с выходом новой версии. Для того, чтобы убрать накладные расходы при динамическом диспатчинге, теперь на этапе компиляции будет генерироваться прямой вызов необходимой функции, используя заданные значения ключа -x. До этого мы в рантайме проверяли, какой у нас процессор, и вызывали нужную версию функции. И хотя overhead не является большим для обычных функций, при интенсивной работе с математическими функциями (например, экспонентой), он может составлять весомые 10%. Особенно востребованным это будет при вычислениях в финансовом сегменте приложений.

Тем не менее, если нам понадобиться вернуть «старое» поведение компилятора, то нам поможет опция -fimf-force-dynamic-target (Linux) или /Qimf-force-dynamic-target (Windows).

Из той же финансовой области пришло и другое изменение. При работе с математикой важна не только производительность, но и воспроизодимость результатов. Я уже писал о замечательных опциях, позволяющих заботиться об этом -fp-model (Linux) и /fp (Windows). Так вот задавая модель работы с числами с плавающей точкой как precise (-fp-model precise (Linux) или /fp:precise (Windows)), мы лишали себя удовльствия использовать векторные математические функции из SVML, что, конечно, отрицательно сказывалось на производительности, но весьма положительно на воспроизводимость результатов. Теперь разработчики позаботились о том, чтобы производительность не влияла на стабильность численных результатов. С помощью ключика -fimf-use-svml (Linux) или /Qimf-use-svml (Windows) можно сказать компилятору использовать скалярные функции из SVML вместо их вызовов из стандартной библиотеки LIBM. А так как они позаботились о том, чтобы скалярные и векторные версии SVML давали одинаковые результаты, то теперь и при использовании precise модели можно использовать векторные математические функции.

При работе с различными буферами используется большое количество функций, например memcpy, memset и т.д. При наличии их вызовов компилятор использует свою внутреннюю логику и может пойти различными путями: вызывать соответствующую библиотечную функцию, генерировать rep инструкции или развернуть операции в цикл при условии, что он знает размер во время компиляции. Так получилось, что он не всегда правильно угадывает нужный подход, поэтому теперь имеется опция -mstringop-strategy (Linux) или /Qstringop-strategy (Windows), с помощью которой можно сказать компилятору, что делать с такими функциям, работающими с буферами/строками (strings, отсюда и название ключика). Можно указать, соответственно, libcall, rep или const_size_loop в качестве аргумента для опции. Например при компиляции с ключом -Os (заботимся о размере наших бинарников), будет неявно использоваться опция -mstringop-strategy=rep.

Для более производительного кода на системах, поддерживающих AVX-512, появилась опция -opt-assume-safe-padding (Linux) или /Qopt-assume-safe-padding (Windows).
Она позволяет компилятору предполагать, что он может безопасно обращаться к 64 байтам после каждого массива или переменной, выделенной приложением. Ранее данная опция была доступна для KNC, теперь же её можно использовать и для последних архитектур с поддержкой AVX-512. В определённых случаях подобная «вольность» позволит компилятору сгенерировать немаскированные операции загрузки вместо маскированных, например, при использовании G2S (gather to shuffle) оптимизации. Но важно выравнивать данные по 64 байта.

Заключение

Это, пожалуй, наиболее важные из новых «волшебных» опций, которые появились в последней версии компилятора. Но кроме всего этого, была добавлена поддержка почти всего стандарта OpenMP 4.5 (нет только user defined recutions), а так же часть нового поколения OpenMP 5.0 (например, редукции в task’ах).
Стандарты С++11 и С++14 полностью поддерживаются ещё с версии 17.0, а вот полная поддержка Fortran 2008 появилась только сейчас. Да и последний стандарт С++17 будет поддерживаться гораздо в большем объёме, и это учитывая, что он ещё окончательно не принят.

В сухом остатке – мы имеем очередную версию компилятора, дающую нам ещё больше возможностей для оптимизации нашего кода и получения лучшей производительности и безопасности кода, при этом с широкой поддержкой самых последних стандартов. Айда тестить?
ссылка на оригинал статьи https://habrahabr.ru/post/329938/