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

Вместе с клиентами меняются каналы доставки им информации, способы предоставления доступа к различным сервисам, каждый из которых имеет свой интерфейс. Идея омниканальности захватила множество разработчиков; рынок инструментов создания, управления и отладки API стремительно расширяется. Как отметил Владимир Амелин, руководитель центра консалтинга компании Aplana, в ходе семинара, посвященного обзору средств работы с OpenAPI, к концу 2016 года насчитывалось уже около 16 тыс. различных API – в эпоху Интернета вещей вести бизнес изолированно невозможно. По мнению аналитиков, лишь 18% из числа крупных банков не планирует в ближайшее время открывать API своих приложений. В России инструменты работы с OpenAPI применяются для обеспечения доступа к сервисам единого портала госуслуг, «Яндекса», Сбербанка, банка «Открытие», МТС, к многочисленным торговым площадкам и другим интернет-ресурсам.

Максим Максименко, системный архитектор Aplana, исторически первым инструментом управления опубликованными API назвал TIBCO Mashery, по сути продолживший эволюционную линейку открытых протоколов и систем — EDI (1990 год), SOAP (1998 год), Web 2.0 (2005 год), направленных на обеспечение взаимодействия машин, приложений и бизнес-процессов. Далее, наряду с программными решениями по проектированию интерфейсов и обеспечению безопасности их применения, с распространением средств аналитики (интеграционная платформа Mule Anypoint Platform) появились программно-аппаратные комплексы поддержки всех этапов жизненного цикла работы с API (например, IBM API Connect). Однако, как отметил Руслан Карпов, руководитель центра разработки и сопровождения Aplana, основной недостаток таких решений – дороговизна, более 60% их стоимости приходится на оборудование. Тем не менее Сбербанк и «Аэрофлот» выполнили ряд проектов на основе API Connect.

Интерес к средствам работы с API проявляют и ведущие игроки цифровой экономики. Например, компания Google в 2016 году приобрела систему Apigee, которая осуществляет управление API, биллинг сервисов, выравнивание пиков нагрузки и предоставляет, в частности, готовый набор стандартных сервисов (геолокация, работа с социальными сетями и др.) или коннекторов к конкретным системам вроде Salesforce, хотя пользователи могут сделать это и с помощью REST либо SOAP.

Андрей Степанов, системный архитектор компании Aplana, обратил внимание на продукт Dell Boomi, предназначенный для разработки API и позволивший компании выполнить в России проект для Philip Morris по интеграции потоков разнообразных данных с десятков сайтов.

Специалисты Aplana отметили следующие ограничения упомянутых инструментов для OpenAPI: ни один из них не поддерживает с достаточным качеством всех операций жизненного цикла работы с API, а отвечает только за какую-либо одну; как правило, поставщики не указывают определенную цену, устанавливая ее в зависимости от конкретного проекта; серверы поддержки обычно расположены за пределами России; непременно требуется тестирование, например на допустимость задержек, происходящих при автоматическом обновлении версии инструментария.

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

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

О том, что все приложения, созданные после 1 февраля 2015 года, должны иметь возможность работать в 64-разрядном режиме, в Apple объявили еще осенью 2014-го, а после июня 2015-го 32-разрядные приложения в App Store не принимаются. В сентябре прошлого года было объявлено, что из App Store будут удаляться приложения, «не работающие, как задумано, не отвечающие правилам или устаревшие»; по всей видимости, это касается и приложений без поддержки 64-разрядного режима.

В Apple не уточняют, с какого момента iOS станет строго 64-разрядной, но можно предположить, что это произойдет в iOS 11, которая, вероятно, будет анонсирована на конференции разработчиков Apple летом. На более старые устройства Apple, имеющие 32-разрядную архтектуру, установить iOS 11 уже не удастся; в их числе — iPhone 5, 5c и более старые, а также стандартный вариант iPad (не Pro или Air) и первый iPad mini.

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

По их словам, идея оптимизации до создания кода управления параллелизмом существует уже давно, но от ее реализации отказывались, предполагая, что придется целиком перерабатывать компиляторы. Но в МТИ пришли к выводу, что это не так — из 4 млн строк кодовой базы универсального компилятора LLVM пришлось изменить только 6 тыс. строк. При этом, как отмечают ученые, использовались механизмы, уже отработанные на оптимизации последовательного кода.

Исследователи убедились в действенности своих идей на программах на языке Cilk — Си с добавлением нескольких команд, позволяющих программисту отмечать участки кода, который можно выполнять параллельно: тесты показали, что программы, скомилированные доработанной версией LLVM, ускоряются на 10-25%. По словам ученых, они легко могут реализовать фронтенд LLVM для любого другого языка, поддерживающего механизмы распараллеливания подобно Cilk.

Легендарный Бьерн Страуструп взялся за задачу упростить обобщенное программирование на C++.

В опубликованном им недавно докладе он напоминает, что концепции — инструмент описания интерфейса шаблонов — одна из основ обобщенного программирования. Доклад создателя C++ так и называется, «Концепции: будущее обобщенного программирования». В концепциях Страуступ видит решение проблемы спецификации интерфейсов, уже давно присутствующей в C++, языке, появившемся более 35 лет тому назад.

«Принципы написания обобщенного кода в C++ слишком сильно отличаются от того, как пишется остальной код», — признал Страуструп.

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

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

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

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

На данный момент механизм концепций уже реализован в CNU C Compiler 6.2. По словам Страуструпа, он рассчитывает, что они станут частью стандарта C++ 20: «Надеюсь, концепции появятся во всех ведущих реализациях языка еще задолго до 2020 года. На мой взгляд, их надо было включить еще в C++ 17, но комитет по стандартизации не смог прийти к консенсусу по этому вопросу».

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

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