...

суббота, 31 октября 2015 г.

Автоматическая генерация программного кода микроконтроллера на основе событийно-ориентированной модели

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

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

Основные требования к системе:

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

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

image

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

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

Таким образом архитектуру системы можно построить на основе 3 видов базовых конструкций:
  • Событие,
  • Триггер,
  • Действие

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

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

image

Триггеры в качестве условия срабатывания могут использовать любое сочетание событий или состояний триггеров (и\или\не).

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

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

Основной код программы
@init
void setup() {
@runonce
}

void loop() { 
@loopcode
}

@triggers
@sensors
@actions



Шаблон кода действия
//@description
void @name()
{       
bool debug=true;
//@id
@code
//@id
  if (debug) {
    Serial.println("DoAction @name");
  }
}



Шаблон кода триггера
//@description
bool @nameActivated=false;
bool @name(){
        if (@nameActivated){
                return true;
        }else
        {       
                if (@event){
                        @nameActivated=true;
                        Serial.println("@name Activated");
                        @nameDoAction();
                        return true;
                }
                return false;
        }       
        return false;
}

void @nameDoAction(){
@nameActivated=true;
//******************************************
@actions
//******************************************
}



Шаблон кода сенсора
//@description
bool @name()
{
        int @namePin=@pinNumber;
        pinMode(@namePin, INPUT_PULLUP);
        int sensorVal = digitalRead(@namePin);
        if (sensorVal == @trueval) {return true;}else{return false;}
}



Пример шаблона инициализации
В данном шаблоне можно подключить библиотеки и объявить глобальные для всего проекта переменные и функции.
#include <etherShield.h>
#include <ETHER_28J60.h>
#include <EEPROM.h>
static uint8_t mac[6] = {0x54, 0x55, 0x58, 0x10, 0x10, 0x24};  
static uint8_t ip[4] = {192, 168, 137, 15};    
static uint16_t port = 80;  
ETHER_28J60 ethernet;
bool started=false;



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

image

После экспорта прошивки мы можем получить подобный код:

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

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

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

Тестовое приложение с типовыми настройками шаблонов можно найти на github.

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Введение в RapidMiner

RapidMiner logoНа данный момент существует много компаний нуждающихся в системах аналитики, но дороговизна и чрезмерная сложность данного ПО в большинстве случаев вынуждает отказаться от идеи построения собственной аналитической системы в пользу простого всем известного экселя. Также дополнительные расходы на обучение сотрудников, поддерживание дорогих систем хранения данных и т.д. И тут на помощь могут прийти Open Source решения — их не так много, но есть очень достойное ПО, одним из которых которых является RapidMiner. RapidMiner (далее просто «майнер») — инструмент созданный для дата майнинга, с основной идеей, что майнер (аналитик) не должен программировать при выполнении своей работы. При этом как известно, для майнинга нужны данные, по этому его снабдили достаточно хорошим набором операторов решающих большой спектр задач получения и обработки информации из разнообразных источников (базы данных, файлы и т.п.), и можно с уверенностью говорить, что это ещё и полноценный инструмент для ETL.

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

К нашему с вами сожалению, с 6 версии создатели майнера решили начать зарабатывать денежку на продажах этого ПО и сменили лицензию с AGPL на Business Source. Тем не менее 5 версия AGPL и мы можем её использовать свободно и без ограничений. По этому в статье будет рассмотрена именно она. Также отметим, что в шестой версии не так много новых операторов и функций (пожалуй самое интересно это поддержка облака), и для большинства задач хватит RapidMiner 5 Community.


Не так давно c официального сайта ссылки на скачивание RapidMiner 5 были удалены, по этому соберем RM из исходного кода который возьмем в официальном проекте на гитхабе.

Для сборки RapidMiner'a из репозитория нам понадобится


Рабочее окно rapidminer Зайдем в консоль, перейдем в каталог куда хотели бы поставить майнер, клонируем репозиторий
git clone http://ift.tt/1M2H6xR

следующий шаг соберем проект
ant build
ant release.makePlatformIndependent

теперь запустим майнер
.\scripts\RapidMinerGUI.bat

для линукса соответственно
./scripts/RapidMinerGUI.sh

Перед вам откроется окно как на картинке справа. Нажимаем на New Process и идем дальше.
Перед тем как на примере посмотреть основные принципы работы с RapidMiner сделаем небольшое введение в его основные понятия.

Процесс


Совокупность операторов соединенных между собой в заданном порядке для выполнения требуемой задачи анализа/обработки данных.
RapidMiner process

Оператор


RapidMiner OperatorЛогическая единица процесса. Оператор производит какие то действия над данными, у него есть вход-выход (так называемые «порты»), на вход приходят данные, на выход идут обработанные оператором данные. Таким образом мы можем делать цепочки обработки данных, к примеру — считать транзакции клиентов из БД, найти самые большие, сконвертировать в доллары и выдать результат. При этом можно цепочки параллелить — к примеру в одной мы читаем транзакции из разных БД, а в другой ищем данные клиентов, потом объединяем и получаем результат (при этом также возможно их параллельное исполнение во времени!).

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

Репозиторий


Место для хранения процессов RM. Может быть локальным, а также удаленным (RapidMiner Server), для которого возможно исполнять процессы на стороне сервера, многопользовательский доступ к процессам/соединениям БД, запуск процессов по расписанию или отдача данных как веб-сервис.

Во вкладе Repositories в RM тут можно увидеть только Samples, DB и Local Repository. Первое как уже понятно из название набор процессов — примеров, DB — текущие соединения к базам данных доступных в майнере (определяются через Tools -> Manage Database Connections) и Local Repository, место для хранения собственных процессов на компьютере.

Контекст процесса


Контексту соответствует вкладка Context где мы можем увидеть три секции:
  • Process input — данные передающиеся на вход процесса. Тут можно указать путь к данными внутри репозитория.
  • Process output — тут указывается путь в репозитории, куда будет сохранен результат работы процесса.
  • Macros — это глобальная переменная доступная в процессе из любого места. Может принимать в качестве значения только строки или числа.

Отметим, что Process input и Process output обозначены в процессе кружками по границе процесса с надписями inp и res. Чтобы воспользоваться данными из входа или сохранить их нужно соединить соответствующий кружок с входом/выходом операторов.

Самое лучшее обучение — практика. Сделаем небольшой процесс на основе которого увидим основные принципы работы с майнером.

Небольшая задачка


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

Первое, что мы сделаем, это сохраним наш эксель файлик в формате CSV и откроем его на чтение в RapidMiner'e. Для этого, возьмем оператор Read CSV (Import -> Data -> Read CSV) и перетянем его в рабочую область процесса. Далее нажимаем на него и видим справа настройки оператора. Нажмём на значок открытой папочки Нажмите для открытия диалогового окна выбора файла, в диалоговом окне выбираем требуемый нам файл (используемый CSV в примере можно скачать по ссылке)

Обратим внимание на нажатую кнопку — режим эксперта. В нём доступны дополнительные параметры для операторов, как правило нужные почти всегда и помечаемые курсивом.

Выставляем параметры как на картинке справа и жмем на Edit list справа от data set meta data information снизу. Выставляем все как на картинке ниже

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

Нажимаем Apply и переходим к следующему шагу. Добавим оператор Filter examples (Data Transformation -> Filtering), его вход соединим с выходом Read CSV, а выход с выходом процесса обозначенным кружочком и надписью res. У вас получится такая картина

С помощью добавленного оператора мы выберем записи только на указанную дату которую объявим как макрос процесса. Идем на вкладку Context процесса, там находим секцию Macros и нажимаем на . В колонке Macro пишем date, а в Value желаемую дату, пусть это будет 30.06.2012.

Так вкладка Context на данном шаге у вас будет выглядеть как на картинке справа. Макрос (напомню, т.е. глобальную переменную) мы определили и теперь воспользуемся им для фильтра записей по дате из нашего CSVшничка. Жмем на оператор Filter Examples выбираем в condition class attribute_value_filter и в parameter string пишем: date = %{date}. Слева мы указали название колонки по которой происходит фильтрация, по центру операция проверки на равенство и справа взятие значения из макроса.

Посмотрим, что получилось. Жмём на кнопочку запуска процесса и майнер переключившись на Result perspective (если этого не произошло нажмите на ) отобразит отфильтрованные данные на 30 июля 2012 года.

Первый результат получен, но нам хотелось бы видеть затраты в рублях по курсу ЦБ РФ. Переключаемся на Design Perspective нажатием на   и добавляем оператор Open file (Utility -> Files -> Open file). Нажимаем на него и выставляем следующие настройки


Где url: http://ift.tt/1M2H4Ge}
Обратим внимание, что мы подставили макрос в параметр оператора.

Получить данные мы получим, но что-то должно их преобразовать в ExampleSet — т.е. таблицу с данными. В первом случае эту роль выполнял Read CSV, а сейчас как не трудно догадаться мы воспользуемся Read XML (Import -> Data -> Read XML). Тянем оператор, соединяем его вход с выходом оператора Open file  и делаем следующие настройки (если вы испытываете трудности с xpath воспользуйтесь мастером импорта нажав наImport configuration wizard).

Обратите внимание, что выставлена галочка parse numbers и разделителем целой и дробной части выставлена запятая.

Необходимо определить какие атрибуты RapidMiner возьмет для ExampleSet. Нажимаем на Edit enumeration справа отxpath for attributes, добавляем две записи

Value[1]/text() — стоимость в рублях единицы валюты
CharCode[1]/text() — буквенный код валюты

Теперь необходимо выставить типы значений для атрибутов. Для этого нажимаем на Edit list справа от data set meta datainformation и выставляем как на картинке ниже

На данном этапе мы имеем процесс который у вас должен выглядеть так

Пришло время сделать конвертацию валют в отфильтрованных по дате данным. Для этого, как можно догадаться, нам потребуется каким то образом объединить котировки и данные. В этом нам поможет оператор Join (Data Transformation -> Set Operations -> Join). Теперь делаем следующее. Берем выход оператора Filter examples, который на данный момент у нас соединен с выходом процесса и соединяем с оператором Join, делаем аналогичное с оператором Read XML.


Теперь нажмем на оператор Join и определим как именно будут объединятся данные. Убираем галочку use id attribute as key, так как объединение у нас происходит по полю currency, появится новый параметр key attributes нажмем слева от него наEdit list, в диалоге Add entry и в обоих полях пропишем — currency. Сохраняем изменения. Можем посмотреть, что получилось, аналогично тому как это делалось выше нажав на кнопочку. Результат будет таким

Мы все ближе к заветной цели — узнать сколько же мы потратили в рублях на наши задачи. Остался последний штрих, собственно сама конвертация. Добавим в процесс оператор Generate Attributes (Data Transformation -> Attribute Set Reduction and Transformation -> Generation) и соединим его вход с выходом оператора Join, а первый выход около которого написано exp (сокращенно ExampleSet)к выходу процесса. Как понятно из названия оператора его задача добавить новый атрибут, для этого нажмем на оператор и справа в его настройках на Edit list, кнопка напротив function descriptions. Дадим название атрибуту и как его считать

Сохраняем изменения и выполняем процесс, наш результат

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

Полезные материалы


This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] 10 главных ошибок масштабирования систем

Организационные и процессуальные вопросы иногда создают проблемы и мешают их исправлять. Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические сбои в малых, средних и больших product-группах. Этот список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу их первой книги.

Архитектурные ошибки



1. Проектирование реализации, но не поиск архитектурного решения


Какие из следующих подходов вы бы использовали для описания архитектуры своего продукта?

Вариант А: «Мы Java-магазин, работающий на GlassFish, Apache Felix с MySQL и СУБД MongoDB».

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

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

2. Проектирование без расчета на ошибку


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


Гибель «Титаника» — один из самых известных примеров ошибки проектирования, стоившей целого проекта: отсеки корабля не были полностью изолированными, и когда корабль дал крен на нос, вода просто переливалась поверх переборок, пока не залила всё

3. Вертикальное масштабирование вместо распределения нагрузки


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

Подобное «решение» в конечном итоге приведет к увеличению расходов на транзакции и большему урону в случае сбоя по мере роста компании. Кроме того, эффективность капиталовложений окажется низкой, так как громоздкая система будет простаивать пока постепенно не вырастет нагрузка. В конце концов, крупнейшая система окажется недостаточно крупной, и у вашего продукта все равно возникнут проблемы. Вспомните eBay 1999 года или PayPal в 2004 году.

4. Использование неверных инструментов


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

Организационные неудачи


5. Разделение по функциям


В прошлом, когда мы создавали и продавали программное обеспечение, роль функциональных менеджеров заключалась в полной изоляции функциональных отделов таким образом, чтобы нейтрализовать все отвлекающие факторы и позволить максимально сосредоточиться на выполнении задачи. Было хорошо, когда каждая команда имела узкоспециализированную направленность, а результат работы передавался на линию сборки. Сегодняшние SaaS-компании производят услугу, и изменения в решение вносятся раз в две недели, а иногда и несколько раз в день. Это обязывает product-менеджеров говорить с инженерами чаще, а инфраструктурных инженеров реагировать еще до начала кодирования. Функциональная организация иногда приводит к снижению качества, медленному выходу на рынок, низкому уровню инноваций и конфликтам между функциональными командами. Лучшие команды сегодня — это многопрофильные, автономные и контролирующие сервис от зарождения идеи до поддержки (по дизайнерскому принципу Уильяма Макдоноу «от колыбели до колыбели» для развития услуг). Если вы сомневаетесь в этом принципе, спросите себя: «Что мы делаем в период кризиса?». Почти всегда ответ будет следующий: «Собираем людей из разных команд, закрываем их в комнате и просим, чтобы они решили проблему». Если это важно в кризис, то почему мы не делаем этого каждый день?

6. Слишком большие команды


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

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

7. Неумение ухаживать за своим садом


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

Если это Java-разработчик, насколько хорошо он кодирует на Java? Категория роста — имеют ли коллеги возможность выйти за пределы их нынешней роли. Готовы ли некоторые из них стать старшими разработчиками? Способны ли они быть архитекторами? Хотят ли и в состоянии руководить? Последняя категория — поведение. Насколько поведение соответствует культуре компании? Эта часто упускаемая из виду категория оказывает наибольший негативный эффект на команду в целом. Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка.

Сбой процесса


8. Неспособность учиться


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

9. Вера в Agile как в панацею


Гибкая методология разработки — великая вещь, но ее использование не решает проблем со структурой команды (см. пункты 5 и 6 в разделе неудач с организацией) или бизнес-задачами, такими как коммуникации между продуктовым и торговым отделом. Понимание Agile как части бизнес-процесса, а не просто теории разработки программного обеспечения очень важно для достижения успеха. Наконец, Agile может исправить часть проблем, для решения которых она предназначена. Ожидать от нее гарантии получения конкретных результатов в конкретные даты аналогично ожиданиям, что плотник починит ваш санузел (см. п. 4 в архитектурных ошибках).

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


Если ваша компания зависит от системы, выполняемой раз в год, например, в кибер-понедельник, то вам необходимо направить все средства на проведение нагрузочного тестирования производительности. Однако, проблема проверки в том, что она проводится на предполагаемых действиях пользователей. Это довольно эффективный способ тестирования, если ПО не меняется. Но в большинстве компаний программное обеспечение меняется часто, а следовательно, часто меняется и поведение клиентов. Клиенты запускают более тяжелые отчеты или делают в два раза больше запросов, если вы измените цвет кнопки поиска. Иначе говоря, их поведение отчасти непредсказуемо. И поскольку тестирование сравнивает текущую версию с базовой, подумайте, как некоторая промежуточная версия будет соотносится с последней? Не следует верить, что результаты тестирования покажут все возможные сбои. Вместо этого, разделение клиентов на зоны изоляции (см. пункт 2 в проблемах с архитектурой) поможет выкатить обновление для небольшой группы пользователей и использовать фактическое поведение клиентов на новом программном обеспечении для проведения тестирования.

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

  • правильно подобранные и применённые инструменты и методологии;
  • грамотный менеджмент в команде;
  • опора на полученный ранее опыт.

Достаточно ли такой триады для успеха софтверного продукта?

Предыдущие посты:

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Генерация кода в Go

Перевод статьи Роба Пайка из официального блога Go о автоматической кодогенерации с помощью go generate. Статья немного устарела (была написана перед выходом Go 1.4, в котором и появился go generate), но хорошо объясняет суть работы go generate.

Одно из свойств теории вычислимости — полнота по Тьюрингу — заключается в том, что программа может написать другую программу. Это мощная идея, которая не настолько оценена, как того заслуживает, хотя и встречается достаточно часто. Это достаточно весомая часть определения того, что делают компиляторы, например. Также, команда go test работает тоже по такому же принципу: она сканирует пакеты, которые нужно тестировать, создаёт новую Go программу, в которой дописан необходимый обвес для тестов, затем компилирует и запускает её. Современные компьютеры настолько быстры, что такая, казалось бы, дорогая последовательность действий исполняется за доли секунды.

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

Таким образом, программы, пишущие программы являются важным элементом в разработке ПО, но программы вроде Yacc, которые создают исходный код, должны быть интегрированы в процесс сборки, чтобы их вывод мог быть передан компилятору. Когда используется внешняя система сборки, вроде Make, это обычно просто сделать. Но в Go, в котором утилита go получает всю необходимую информацию о билде из исходных кодов, это проблема. В нём просто нет механизма, чтобы запустить Yacc с помощью go tool.

До этого момента, в смысле.

Последний релиз Go, 1.4, включает в себя новую команду, go generate, которая позволяет запускать подобные утилиты. Она называется go generate, и при запуске сканирует код на наличие специальных комментариев, которые указывают, какие команды нужно запускать. Важно понимать, что go generate не является частью go build. Она не анализирует зависимости и должна быть запущена до go build. Она предназначена для автора Go пакета, а не для его пользователей.

Команда go generate очень проста в использовании. Для разминки, вот как её использовать, чтобы сгенерировать Yacc грамматику. Скажем, у вас есть входной Yacc-файл, называющийся gopher.y, который определяет грамматику вашего нового языка. Чтобы сгенерировать код на Go, который будет парсить эту грамматику, вы обычно запустили бы стандартную Go-версию yacc, как-нибудь так:

go tool yacc -o gopher.go -p parser gopher.y

Опция -o тут указывает имя результирующего файла, а -p — имя пакета.

Чтобы переложить этот процесс на go generate, нужно в любом обычном (не автосгенерированном) .go файле в этой директории добавить вот такой комментарий:
//go:generate go tool yacc -o gopher.go -p parser gopher.y

Этот текст это та же самая команда, но с добавленным вначале комментарием, который распознает go generate. Комментарий должен начинаться в начале строки и не иметь пробелов между // и go:generate. После этого маркера, оставшаяся часть указывает, какую команду go generate должен запускать.

А теперь запустите её. Перейдите в исходную директорию и запустите go generate, затем go build и так далее:

$ cd $GOPATH/myrepo/gopher
$ go generate
$ go build
$ go test

И это всё, что нужно. Если нет никаких ошибок, то go generate вызовет yacc, который создаст gopher.go, на этом моменте директория будет содержать все необходимые go-файлы, которые мы можем собирать, тестировать и нормально с ними работать. Каждый раз, когда gopher.y меняется, просто перезапустите go generate, чтобы пересоздать парсер.

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

Go generate не делает ничего, что не могло бы быть сделано с помощью Make или другого механизма сборки, но он идёт из коробки в команде go — не нужно ничего устанавливать дополнительно — и он хорошо вписывается в экосистему Go. Главное, помните, что это для авторов пакета, не для пользователей, хотя бы из соображений того, что программа, которая будет вызываться, может отсутствовать на машине пользователя. Также, если пакет предполагается использоваться с go get, не забывайте внести сгенерированные файлы в систему контроля версий, сделав доступными для пользователей.

Теперь, давайте посмотрим, как можно использовать это для чего-то нового. В качестве радикально иного примера, где go generate может помочь, в репозитории golang.org/x/tools есть новая программа stringer. Она автоматически генерирует строковые методы String() для наборов числовых констант. Она не входит в стандартный набор Go, но её легко установить:

$ go get http://ift.tt/11KS62y

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

type Pill int

const (
    Placebo Pill = iota
    Aspirin
    Ibuprofen
    Paracetamol
    Acetaminophen = Paracetamol
)

Для отладочных целей, мы хотели бы, чтобы эти константы могли красиво отдавать своё название, другими словами, мы хотим метод со следующей сигнатурой:
func (p Pill) String() string

Его легко написать вручную, например как-то так:
func (p Pill) String() string {
    switch p {
    case Placebo:
        return "Placebo"
    case Aspirin:
        return "Aspirin"
    case Ibuprofen:
        return "Ibuprofen"
    case Paracetamol: // == Acetaminophen
        return "Paracetamol"
    }
    return fmt.Sprintf("Pill(%d)", p)
}

Есть несколько способов написать эту функцию, разумеется. Мы можем использовать слайс строк, индексированный по Pill, или map, или какую-нибудь другую технику. Так или иначе, мы должны поддерживать его каждый раз, когда мы меняем набор лекарств, и мы должны проверять, что код правильный. (Два разных названия для парацетамола, к примеру, делают этот код чуть более мудрёным, чем он мог бы быть). Плюс, сам вопрос выбора способа реализации зависит от типов значений: знаковое или беззнаковое, плотное и разбросанное, начинающиеся с нуля или нет и так далее.

Программа stringer берёт эти заботы на себя. Хотя она может запускаться и вручную, но она предназначена для запуска через go generate. Чтобы использовать её, добавьте комментарий в исходник, скорее всего, в коде с определением типа:
//go:generate stringer -type=Pill
Это правило указывает, что go generate должна запустить команду stringer, чтобы сгенерировать метод String для типа Pill. Вывод автоматически будет записан в файл pill_string.go (вывод может быть переопределён с помощью флага -output).

Давайте запустим её:

$ go generate
$ cat pill_string.go
// generated by stringer -type Pill pill.go; DO NOT EDIT

package pill

import "fmt"

const _Pill_name = "PlaceboAspirinIbuprofenParacetamol"

var _Pill_index = [...]uint8{0, 7, 14, 23, 34}

func (i Pill) String() string {
    if i < 0 || i+1 >= Pill(len(_Pill_index)) {
        return fmt.Sprintf("Pill(%d)", i)
    }
    return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
}
$

Каждый раз, когда мы меняем определение Pill или констант, всё что мы должны сделать, это запустить
$ go generate

чтобы обновить String метод. И конечно, если у нас есть несколько типов в одном пакете, которые нужно обновить, go generate обновит их всех.

Само собой разумеется, что сгенерированный код уродлив. Это OK, впрочем, так как люди не будут работать с этим кодом; автосгенерированный код очень часто уродлив. Он старается быть максимально эффективным. Все имена объединены вместе в одну строку, которая экономит память (всего одна строка на все имена, даже их тут несметное количество). Затем массив, _Pill_index, находит соответствие типа с именем используя простую и очень эффективную технику. Обратите внимание, что _Pill_index это массив (не слайс; одним заголовком меньше) значений типа uint8, наимейший возможный целочисленный тип, способный вместить в себя нужные значения. Если значений будет больше, или будут отрицательные, тип сгенерированного массива _Pill_index может поменяться на uint16 или int8, смотря что будет работать лучше.

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


const _Power_name = "p0p1p2p3p4p5..."

var _Power_map = map[Power]string{
    1:    _Power_name[0:2],
    2:    _Power_name[2:4],
    4:    _Power_name[4:6],
    8:    _Power_name[6:8],
    16:   _Power_name[8:10],
    32:   _Power_name[10:12],
    ...,
}

func (i Power) String() string {
    if str, ok := _Power_map[i]; ok {
        return str
    }
    return fmt.Sprintf("Power(%d)", i)
}

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

В исходных кодах Go есть масса других примеров использования go generate. Сюда входят генерация таблиц Unicode в пакете unicode, создание эффективных методов для кодирования и декодирования массивов в encoding/gob, создания набора данных таймзон в пакете time, и тому подобное.

Пожалуйста, используйте go generate креативно. Он тут для того, чтобы поощрять эксперименты.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Руководство по поиску работы для MDA-специалиста (и немного про метод анализа иерархий, Xcore и Sirius)

[unable to retrieve full-text content]




Это 4-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы познакомились с OCL и метамоделями, Eclipse Modeling Framework и Sirius. Сегодня научимся описывать метамодели в текстовой нотации (а не в виде диаграмм как раньше) и познакомимся с табличным представлением моделей в Sirius. Сделаем это на примере кризиса среднего возраста и метода анализа иерархий. Возможно, это пригодится вам при разработке ИИ в играх, при принятии решений или в работе.
Читать дальше →

Пользовательская документация и GitHub

      Сталкивались ли вы когда нибудь с долгим поиском документации к используемой библиотеке или пакету? Я считаю странным, что исходный код не распространяется с пользовательской документацией. Ведь она такая же важная часть кода, как тесты или зависимости. Без хорошей пользовательской документации мы можем «убить» уйму времени на анализ кода и комментариев. Так почему бы не хранить пользовательскую документацию вместе с исходными кодами программы? Речь не о DocBlock и генерацию документации по API проекта, я говорю именно о пользовательской документации, которую мы так любим за последовательное повествование и множество примеров.

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

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


      В отличии от документации, добавляемой прямо в исходные коды (в виде комментариев), пользовательская документация более «user-ориентированная», если можно так выразится. Представьте, что вы долго искали подходящую библиотеку и вдруг коллега назвал ту, которая «может вам подойти». Вы быстро находите ее на GitHub, но с чего начать? Хорошо если в корне есть файл README.md, но даже ознакомление с ним может оставить множество вопросов. Обычно все заканчивается одним исчерпывающим примером (если библиотека не большая) или ссылкой на официальную документацию в виде Web-сайта или PDF документа. После доступа к одному из этих ресурсов вы вздыхаете с облегчением, внимательно читаете несколько страниц, изучаете пятерку примеров и начинаете уверенно пользоваться библиотекой.

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


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

      Вы храните unit-тесты вашего проекта вместе с кодом или в отдельном репозитории? Обычно они находятся в каталоге tests и являются неотъемлемой частью проекта. С документацией так же. Она — часть вашего проекта, но в отличии от тестов, она нужна пользователям не для проверки работоспособности вашего решения, а для быстрого и безболезненного ознакомления с ним.

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

Пример
1. [Введение](./getting-started.md)
2. [Обработка файлов](./files.md)
3. [Работа в сети](./network.md)


      Рекомендую так же использовать файл «Введение» (getting-started.md), который можно использовать для «быстрого старта». В нем должны быть кратко и доступно описаны основные возможности вашего решения с примерами и комментариями. Информации в этом файле должно хватить для того, чтобы начать пользоваться вашим решением на пользовательском уровне.

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


      Остальные файлы должны содержать подробное описание компонентов вашего решения, подробные примеры использования и возможные проблемы, с которыми может столкнуться пользователь. Лучше, чтобы эти файлы не были связаны друг с другом, чтобы пользователь мог начать изучение того компонента, который он считает нужным.
      После того, как пользовательская документация будет готова, добавьте в корень вашего проекта файл README.md, в котором будет ссылка на «точку входа» вашей документации.
Пример
# Bricks.Cli.Routing

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

## Установка и Автозагрузка

Этот пакет сопровождается файлом [composer.json][], что позволяет использовать 
[Composer][] для его инсталляции и автозагрузки.

Так же можно установить его загрузив [исходные коды][] пакета в виде Zip архива 
или клонировав этот репозиторий. Все компоненты этого пакета загружают 
зависимости автоматически.

Перед использованием рекомендуется выполнить тестирование с помощью утилиты 
[PHPUnit][] вызвав ее в корневом каталоге пакета.

## Зависимости

Этот пакет зависит от интерпретатора PHP версии 5.5 или выше.

## Поддержка

Если у вас возникли сложности или вопросы по использованию пакета, создайте 
[обсуждение][] в данном репозитории или напишите на электронную почту 
<Artur-Mamedbekov@yandex.ru>.

## Документация

Пользовательскую документацию можно получить по [ссылке](./docs/index.md).

Документацию API можно получить из исходных кодов пакета или с помощью утилиты 
[Doxygen][].

[composer.json]: ./composer.json
[Composer]: http://getcomposer.org/
[исходные коды]: http://ift.tt/1P2acDF
[PHPUnit]: http://phpunit.de/
[обсуждение]: http://ift.tt/1Mnma45
[Doxygen]: http://ift.tt/v4LzZV


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

      Так как вся документация находится в репозитории, на нее удобно ссылаться извне по ссылке вида: http://ift.tt/1P2abiY — а если «прикрутить» сюда Web-интерфейс, то можно получить полноценный Web-сайт без необходимости переноса документации. Удобно не правда ли?

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


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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[recovery mode] Pony — убийца...?

Всем известны такие прогрессивные новички в программировании, как — «Go, Rust, Nim, Crystal» и, все они очень круты в своих определенных областях.

К примеру:

  1. Go был рожден, как супер простой и промышленный язык для быстрого решения поставленных задач с идеями, которые всем прекрасны известны, но некоторые из них прибиты к другим языкам гвоздями (На 5мм).
  2. Второй наш оппонент — это Rust, победитель по жизни, но из-за своей сложной жизни в развитии он стал для сообщества, как будущая и модная замена C++. Для меня его судьба пока не понятна, так как с зелеными потоками и IO под них там пока туго, то я его ставлю на место в ряд с C для микроконтроллеров, драйверов и операционных систем.
  3. Crystal… Прямо и четко говорю, что это супер производительный клон Ruby. Больше сказать нечего, весь он пропитан его духом.
  4. Nim (Он же Нимушка или Нимрод) и его похожесть на скриптовые языки создают ему особую атмосферу, однако внутри он достаточно сложный организм и для меня сия сущность, как Haxe с такими же ощущениями при программировании на нем.

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

Это только начало


Предварительно расскажу немного о себе, чтобы создать вам особую атмосферу для понимания языка и его возможных применений.
  • Я — Nyarum, известен, как простой пользователь языка Go. Часто задвигаю иронию с Растом и являюсь соавтором Slack сообщества гоферов.
  • Мои петпрожекты всегда связаны с эмулированием онлайн игр. От реверса до воспроизведения серверной части.
  • И я очень люблю Аниме.

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

Язык и краткий ликбез

image
Это тот самый жизнерадостный кормилец и он больше похож на кролика

Pony — объектно-ориентированный язык программирования, построенный в первую очередь на модели акторов и прозрачной конкурентности. В его дополнительных плюсах трутся такие понятия, как — «Open-source, производительность, интересные идеи». Основной упор идет на многоядерный системы, современную разработку без мыслей о низком уровне и очень производительную конкурентность.

Возможности

  • Типобезопасность. Подтвержденная математическим бекграундом.
  • Безопасная работа с памятью. Хоть это и является следствием из типобезопасности, но нельзя упускать данный пункт. В нем вы не найдете повисших указателей, переполнение буффера или в самом частом случае — вам не придется знать, что такое null.
  • Безопасная работа с экзепшенами. Все они определяются на семантическом уровне и никаких рантайм неожиданностей.
  • Скажем нет гонкам данных! Никаких атомиков, мьютексов или таймеров. Система типов с проверками во время компиляции дают высокую гарантию сего понятия. Пишите конкурентный код и не переживайте за остальное.
  • Никаких дедлоков. Следствие из отсутствия любых операций с блокировками.
Краткая спецификация по языку

Система типов:

  • Класс, стандартен из ООП мира. Поля, конструкторы и функции в вашем распоряжении.
    class Habra
      let _name: String
    
      new create(name': String) =>
        _name = name'
    
      fun name(): String => _name
    
    

  • Актор, идентичен классу, но имеет возможности определения ассинхронных функций. Это относится к прозрачной конкурентности.
    actor Habro
      let name: String
      var _hunger_level: U64 = 0
    
      new create(name': String) =>
        name = name'
    
      be eat(amount: U64) =>
        _hunger_level = _hunger_level - amount.min(_hunger_level)
    
    

  • Примитив, тоже идентичен классу с 2-я различиями. Он не может иметь полей и в процессе работы программы создается только 1 инстанс на определенный вами примитив. Используется для многих вещей, но чаще, как особый вид дженерика с возможностью в None тип, чтобы проверять приходящие из FFI мира значения, не равняется ли оно пустоте.
    primitive _Habras
    
    

  • Трейт и интерфейс (Являются подтипами, однако определяются так же, как и класс). Многие ЯП имеют только 1 из них одновременно, но в Пони они задействованы оба. Различие в том, что трейт является условной проверкой принадлежности, а интерфейс проверяет соответствие структурно.
    // Trait
    trait Family
      fun age(): U64 => 5
    
    class Habravi is Family
    
    // Interface
    interface Habrovik
      fun name(): String
    
    class Habrovichek
      fun name(): String => "Model #1"
    
    

  • Алиасы для типов. Не буду говорить тут про них много, мощная система и требует самостоятельного изучения.
    // Enumeration
    primitive Red
    primitive Blue
    primitive Green
    
    type Colour is (Red | Blue | Green)
    
    // Complex
    interface HasName
      fun name(): String
    
    interface HasAge
      fun age(): U32
    
    interface HasAddress
      fun address(): String
    
    type Person is (HasName & HasAge & HasAddress)
    
    

  • Кортеж есть последовательность типов, которые могут быть определены в одной переменной.
    var x: (String, U64)
    x = ("hi", 3)
    
    

  • Юнион очень похож на кортеж, только используется для обобщения возможных типов. Особый вид дженерика.
    var x: (String | U64)
    x = "hello habr"
    
    // or
    
    x = 5
    
    

  • Пересечение почти является противоположностью юниона и может описывать одно значение для нескольких типов одновременно. В примере ниже видно, как карта может содержать одновременно ключ двух разных типов.
    type Map[K: (Hashable box & Comparable[K] box), V] is HashMap[K, V, HashEq[K]]
    
    

  • Все выше описанные выражения типов могут комбинироваться
    // Tuple in Union which in Array
    var _array: Array[((K, V) | _MapEmpty | _MapDeleted)]
    
    

Стандартные выражения:

  • Это всем очень хорошо знакомые — «Переменные, знаки операций, проверки, циклы, методы, экзепшены, etc..». Оставляю на самостоятельное изучение.
Возможности:

Привлекательность языка

Сборщик мусора

На борту мы имеем очень крутой GC, который является полностью конкурентным и не имеет Stop the World. На самом деле там их 2, один является сборщиком ссылок для каждого созданного актора и один глобальный.
Скорость акторов

Благодаря такому парню, как Дима Вьюков, который внес огромный вклад в lock-free алгоритмы и Go — появилась база, на которую делал упор Pony при разработке общения акторов. И именно поэтому сейчас скорость передачи между акторами достигает 20кк в секунду, а создание может достигать 1кк в секунду.
Прозрачная конкурентность

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

Статус и дополнительные ссылки


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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Будущее Web очень напоминает Bitcoin

image

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

Зимой 2014 года он позвал меня с собой на биткоин-конференцию в Майами, чтобы рассказать о новом проекте Ethereum, который он с единомышленниками из Канады запустил за несколько месяцев до этого. Когда он объяснил мне суть проекта, он не скупился на прогнозы: «Мы заменим страховые компании и Уолл Стрит».

Список продолжал расти. Онлайн-сервисы по распространению фильмов вроде Netflix и Hulu. Игровые платформы вроде Xbox и Sega Genesis. Мессенджеры вроде Twitter. Пенсии, обмены валют, системы голосования, управление интеллектуальной собственностью, трастовые фонды. Если верить Любину, то всё – реально всё, что мы делаем через интернет или по другим цифровым каналам, претерпит радикальные изменения.

Рассказанная им идея с тех пор завладела умами энтузиастов цифровых валют. Идея в том, что технология, обеспечивающая безопасные транзакции в сети биткоин, и делающая их прозрачными, очень быстрыми и нецензурируемыми, и не требующими доверия другим сторонам, может использоваться для обработки более сложных сделок и хранить любую цифровую информацию в интернете.
За последний год эта теория развивалась очень непоследовательно и неорганизованно. Уже существуют распределённая система доменных имён, цифровой нотариат, не требующий услуг третьей стороны, и сервисы по управлению финансовыми контрактами через децентрализованные эксроу-аккаунты. Некоторые эксперименты проходят в самой сети биткоин. Другие проекты, как и Ethereum, запустили новые сети или подключаются к альтернативным цифровым валютам – клонам биткоин. Многие начинания уже получили финансирования. В январе Spark Capital и израильская фирма венчурных инвестиций Aleph профинансировали стартап Colu на $2,5 миллиона.

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

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

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

Ник Забо [Nick Szabo] (чьи теории по цифровым контрактом и умной собственности заслужили ему такое уважение в среде поклонников цифровых валют, что его постоянно обвиняют в создании сети биткоин), суммирует проблему в своём блогпосте:

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

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

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

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

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

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

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

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

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

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

image

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

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

Стратегия, продуманная Сатоси Накамото (псевдоним архитектора биткоин) для достижения консенсуса в этой системе, считается прорывом в распределённых вычислениях.

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

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

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

«Вы строите гигантскую стену»,- говорит Питер Кирби, президент Factom. «И каждый раз, когда вам нужно о чём-то договориться, вы кладёте наверх тысячу кирпичей. Договариваетесь о чём-либо ещё, и кладёте ещё одну тысячу кирпичей сверху. Это делает очень, очень сложным делом для кого угодно убрать один кирпичик снизу стены».

Не верите? Давайте проведём атаку на систему.

Допустим, в цепочке блоков биткоин имеется запись, которую я хочу изменить, и она содержится в сотом блоке цепи. Тем временем сообщество майнеров уже решает блок № 110. Чтобы мои изменения были приняты сетью, мне нужно предоставить мою альтернативную версию всей цепочки. Мне надо откатиться до блока 100, изменить запись, и выполнить необходимые расчёты. Поскольку все последующие хэши основаны на изменённых мною данных, мне придётся повторить работу над каждым из последующих блоков, вплоть до 110.

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

А это большая сеть. Соревнуясь друг с другом, майнеры инвестируют в компьютеры со специализированными чипами, ASIC, которые разработаны для подсчёта хэшей. Скорость обработки компьютеров в сети удвоилась с августа 2014 по март 2015, и цифры всё растут. Некоторые из этих вычислительных центров – это гиганты, потребляющие по 500 киловатт и требующие специально подобранного жидкостного охлаждения.

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

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

«Это и есть главный вклад,- говорит Иттай Ийял [Ittay Eyal], специалист по информатике из Корнелла, изучающий биткоин и другие децентрализованные сети. Биткоин устроен так, что атакующему выгоднее работать вместе с системой, а не атаковать её. Система побуждений поощряет вносить вклад при помощи своих ресурсов на благо системы».

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

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

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

Когда метаданные включаются в цепочку, они получают все преимущества использования p2p сети. Эти данные доступны любому на планете, имеющему компьютер и подключение к интернету. Чтобы уничтожить их, вам понадобилось бы достучаться до каждого компьютера в сети. Их невозможно изменить, и значит, невозможно применять к ним цензуру. У них есть как время создания, так и криптографическое доказательство авторства.

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

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

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

Цепочка также решает проблему цензуры. Если один раз вставить метаданные в цепь, их уже невозможно убрать оттуда. Разработчики использовали эту возможность для создания нецензурируемой версии Twitter под названием Twister и децентрализованной системы доменных имён (Namecoin).

«Всё, чем вы владеем и что делаем, управляется пачкой записей»,- говорит Кирби. «Банк – это просто куча записей. Страховая компания – куча записей. Экономика – это куча записей. Если вы можете принять концепцию мирового гроссбуха и сказать: „Теперь мы можем организовать таким образом все записи в мире“, то это очень здорово».

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

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

А что если попросить майнеров сделать что-то ещё? К примеру, «не одобряйте транзакцию, пока я жив». Или «при одобрении транзакции подправьте количество отправляемых монет с учётом цены акций Tesla Motors».

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

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

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

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

Изменения в протоколе требуют времени. Чтобы убедиться, что все участники сети играют по правилам, нужно так вносить изменения, чтобы они удовлетворили всех заинтересованных лиц. Этот процесс может быть утомительным. Некоторые считают, что он ограничивает эволюцию биткоина. «Сейчас существует уже пять разных сторон, участвующих в нахождении консенсуса: разработчики, майнеры, продавцы, пользователи и провайдеры услуг. Обычно требуется согласие всех пяти сторон, чтобы внести изменения в протокол,- говорит Андре Антонополус [Andreas Antonopoulos], автор инструкции „Осваиваем биткоин“. – Мы приближаемся к окончанию эры, в которой были возможны радикальные изменения».

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

Недавно компания Blockstream, основанная Бэком вместе с десятком других уважаемых в сообществе людей, выпустила реализацию сторонних цепочек с открытым кодом под названием Sidechain Elements.

Тем временем Ethereum не ждёт, пока цепочка блоков биткоин подтянется до его амбиций. Это проект, работающий с новой цепочкой, который хочет превратить сеть майнеров в рабочий распределённый компьютер. Вместо раздачи майнерам нескольких новых команд, которые нужно выполнить во время обработки транзакции, Ethereum позволяет им запускать любые программы. Это значит, что майнеры могут запускать софт, вообще не имеющий отношения к транзакциям. Теоретически платформу можно будет использовать для взаимодействия с любым приложением, заменяя набор интернет-серверов одной большой распределённой виртуальной машиной. Конечная цель выглядит вовсе фантастичной. «Мы строим новый тип интернета»,- утверждает Любин.

«В проекте Ethereum, поскольку каждый узел является полноценной виртуальной вычислительной машиной. разработчик может загрузить транзакцию с компьютерным кодом, и добавить её в сеть,- говорит он. – Система распознает его и установит код на каждом узле сети. Через несколько секунд ваше приложение будет работать по всему миру».

Взаимодействие с приложениями заключается в отправке «эфиров» (ethers, аналог биткоинов) в сеть и запросе доступа к софту в цепочке блоков.

Финансирование проекта было исключительно успешным. Зарегистрированная в Швейцарии некоммерческая организация Ethereum Foundation решила получить финансирование, продавая эфиры всем желающим. В отличие от биткоина, Ethereum Network была разработана так, чтобы создать набор монет-эфиров до начала работы сети. Прошлым летом в течение 42 дней фонд продавал часть своих резервов в обмен на биткоины. Продажа принесла 31529 бикоинов (на тот момент аналог $18 миллионов, но сейчас это уже раза в два меньше).

За последние месяцы разработчики показывали предварительные версии своего софта на различных встречах. В марте в Нью-Йорке Коннор Кинан показал приложение, выполняющее все функции веб-форума типа Reddit. Код программы записан в софтовый объект под названием «контракт» в тестовой версии цепочки Ethereum. Для использования программы необходимо создать и распространить по сети транзакцию (потратив небольшое количество эфиров, отправив их на адрес контракта). Майнеры запустят локальные копии этой программы на своих компьютерах, позволяя вам добавлять посты и комментарии, и т.п. Другой докладчик показал рудиментарную видеоигру.

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

Возьмём аренду автомобилей. Вместо того чтобы идти к окошку и общаться с человеком, который проведёт вашу кредитку и выдаст вам ключи, вы отправляете транзакцию через Ethereum, устанавливающую контракт между вами и фирмой-арендатором. Эта оплата будет и тем кодом, который активирует смарт-карту (или мобильное приложение, или любой другой вид ключа), чтобы вы могли завести машину. Другие программы в цепочке блоков отследят количество пройденных километров и подсчитают стоимость аренды, а прибыль будет автоматически отправлена владельцам компании. Приверженцы биткоинов считают, что эта модель не только не нужна, но и опасна. «Я с недоверием отношусь к сложным идеям – распределённым автономным корпорациям, работающим независимо и каким-то чудесным образом обеспечивающим свою безопасность»,- говорит Гэвин Андресен, один из основных разработчиков биткоин-протокола. «Может быть, когда-нибудь, когда у нас будут робомобили и роботы-инспекторы, мы сможем позволить себе компанию, управляемую кодом без людей. Может быть, тогда нам и понадобятся сложные контракты в цепочке блоков. Но я считаю, что до этого ещё очень далеко».

Если мы и придём туда, считает Любин, то не через биткоин. «Это очень узкий протокол. Он делает только одну вещь, и делает её хорошо,- говорит он. – Наверно, можно было бы построить всё, что умеет Ethereum, через биткоин. И это заняло бы у вас в 10-100 раз больше времени. В Ethereum всё происходит на уровне приложений. Он превращает всё на уровне приложений в софт, написание которого доступно миллионам людей – в отличие от сложной возни с криптографическими примитивами».

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

пятница, 30 октября 2015 г.

Дайджест: Чему мы научили поиск за это лето

Привет, Хабр! Цыплят, как известно, по осени считают. Осень в самом разгаре, давайте смотреть, чему мы научили поиск Google за это лето.

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

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


140 символов одного поста могут вмещать на удивление много информации. Крайне простой и минималистичный на старте сервис сейчас оброс фичами и объединяет весь мир, является одним из самых быстрых «новостных агентств», помогает людям в самых неожиданных ситуациях (в том числе и предупреждать о произошедших ЧС). Поиск Google позволяет получать результаты непосредственно из этой социальной сети прямо в поисковой выдаче в виде карточек.

Запросы вида %объект_интереса% Twitter приводят к последним записям от соответствующего аккаунта, если он существует. А запросы по популярным хэштегам позволяют посмотреть последние записи, не переходя к веб-версии Twitter’а или к соответствующим приложениям.

Введено в конце мая для некоторых языков. Пока русского языка среди них нет.


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

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

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

Другой пример — работа с потоковым плеером Spotify. У вас запущена какая-либо композиция, и вы хотите побольше узнать о вокалисте группы? Просто воспользуйтесь Контекстом от Google Now. Спросите «Кто вокалист группы». Остальную информацию он самостоятельно возьмёт из контекста запуска: в данном случае, из плеера Spotify.

Маленькое изменение, призванное сделать ваш смартфон ещё умнее. Будет Стало доступно для английского языка с релизом Android M.


Не забыли мы и про пользователей iOS. Вызвать Now on Tap на iPhone не выйдет, но мы научили поиск Google работать с данными приложений iOS. Данная возможность более двух лет присутствует на Android-девайсах, но реализовать её на iOS получилось только с выходом восьмой версии яблочной операционки.

На момент запуска (начало июня) поиск внутри контента приложений по разным причинам был доступен в ограниченном количестве приложений. В США Google Поиск умеет взаимодействовать с Eat24, Free Dictionary, Huffington Post, OpenTable, Pinterest, SeatGeek, Slideshare, Tapatalk, Yellow Pages, YouTube и Zillow, также поддерживаются некоторые приложения в Бразилии, Германии, Японии и Австралии. Кроме того, на подходе десятки других (наиболее популярных и полезных) приложений, в том числе и в других странах. Если вы разработчик iOS приложений и хотите внедрить подобную фичу у себя — в конце этой записи в нашем блоге есть краткая инструкция по интеграции с поиском Google на iOS.


Взаимодействие между приложениями в Android реализовано намного свободнее, поэтому мы смогли научить Google Now (который отлично распознаёт простую человеческую речь) отправлять текстовые сообщения в самых популярных мессенджерах. Просто скажите, кому и что отправить, а остальное приложение Google сделает за вас:

На данный момент поддерживаются WhatsApp, Viber, Telegram, NextPlus и WeChat. На момент запуска (конец июля) данная фича работала только с Английским языком, сейчас для русского языка 100% работают Vk и GetTaxi. Список партнёров потихоньку расширяется, мы обязательно расскажем о возможностях этих взаимодействий отдельно.

P.S.: А ещё раньше, весной, мы научили карточки приложений взаимодействовать с голосовым поиском на уровне запросов. Например, «shazam this song» запустит автоматическое распознание музыки с помощью сервиса Shazam, конечно, при учёте наличия у вас соответствующего приложения и последней версии Поиска Google на смартфоне*.



* — Для корректной работы потребуется переключить голосовой Поиск Google на английский язык как основной. Если Shazam у вас нет, вы выбрали русский язык как основной, а вокруг играет отличная незнакомая композиция, просто произнесите «О’кей, Google!». Поиск Google сам поймёт, что где-то звучит музыка. Всё, что вам останется — нажать на «ноту» в нижнем-правом углу.

Дополнить прекрасную картину по интеграции поиска и мобильных приложений может обновление нашего сервиса по сокращению ссылок Goo.gl. Мы добавили поддержку кроссплатформенной интеграции в приложения. Например, вы хотите поделиться своим местоположением с помощью Google Карт. Вы нажимаете кнопку «Поделиться», специальные API генерируют сокращённую ссылку, и когда получатель по ней тапнет, начнётся магия. Сервис Goo.gl определит платформу пользователя, установлено ли на устройстве соответствующее приложение, и, если да — откроет результат именно в нём. Просто, удобно, в один клик.
Как вы все уже успели заметить, логотип Google, который оставался практически неизменным с 1999 года полностью обновился 1 сентября 2015. Новый, чистый и простой визуальный стиль должен органично вписываться в концепцию Material Design, а наш ключевой продукт — Поиск Google — соответствовать современному корпоративному стилю. Мы обновили Google Now таким образом, чтобы он не только соответствовал Material Design’у по духу, но и полностью отражал все современные возможности как поисковой системы, так и визуального языка, на основе которого построены Android 5.0 и 6.0.
Если вы, как пользователь Поиска Google, рады новым фичам, то не стоит забывать и про тех, кто реализует радующие вас возможности в приложениях с помощью наших технологий: о разработчиках. Есть ряд сложных задач, которые не исправляются за минуту, требуют подготовки новых стандартов или полного пересмотра текущих алгоритмов работы. Тем не менее, и на улице «скучных технологий» сегодня праздник.
Развитие локализованных доменов потребовало соответствующей адаптации и разных не-юникод элементов сети Интернет, и работы внутри самого Google. Сейчас внедряются всё новые и новые gTLD (англ. generic Top-Level Domain — Общий домен верхнего уровня), и мы сделали так, чтобы поиск Google адекватно реагировал на них.

Например, новые gTLDs никак не влияют на ранжирование результатов поиска. Нет разницы, ищете вы сайт в доменной зоне .com, .org или какой-нибудь новой, типа .BRAND. Ключевые слова внутри самого домена никак не повлияют на результаты и порядок выдачи.

Также мы позаботились о поддержке японских и китайских национальных алфавитов. Вы можете убедиться в этом, задав поисковый запрос [site:みんな]. К сожалению, есть ряд ограничений, накладываемых на самих владельцев сайтов (например, все ссылки должны быть заданы в Юникоде, чтобы поисковая система могла нормально их интерпретировать именно как ссылки).

К слову, разницы в том, в каком формате будут ссылки (в национальном, при помощи Unicode, или в приведённом к ASCII через Punycode) для поисковика нет никакой, и на результаты, опять же, формат записи ссылок не повлияет.

Все остальные вопросы по gTLD (в основном, касающиеся географически привязанных доменов (например, .london)) либо не влияют, либо влияют на результаты поиска незначительно. Мы стараемся не использовать информацию из доменного имени, а привязывать результаты к geotarget’у, если это возможно. Вопросы по многоязычным и мультирегиональным сайтам рассмотрены в нашем Справочном центре.

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


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

Вид поисковой строки ~2004 года

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

Годами данная фича имела закрытые внутренние API, которые некоторые сторонние разработчики использовали через неофициальные инструменты, разработанные методом реверс-инжиниринга. Они позволяли использовать подстановку поисковых запросов независимо от самого Поиска Google.

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

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

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

С 10 августа мы ограничили неавторизованный доступ ко внутренним API автодополнения. Для тех разработчиков и владельцев сайтов, которые хотят использовать автодополнение мы готовы предложить альтернативное решение. Наш сервис Google Custom Search Engine позволяет использовать все возможности автодополнения запросов вместе с поиском по сайту. Для всех, кто уже пользуется Google CSE никаких изменений не произойдёт, а всем желающим приобщиться к этой технологии будут рады вот здесь.


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

В августе мы обновили Google Search Analytics в Search Console, добавив возможности доступа к данным через новые API. Мы надеемся, это поможет веб-мастерам собирать важную статистику в удобном для них виде. Если вы уже пользовались какими-либо Google API, то работать с Search Analytics API для вас не составит никакого труда. Если же вы новичок в этом плане, то специально для вас у нас есть страница с кратким руководством по применению API и примерами на Python’е.

Например, вы можете узнать, насколько свежие данные с вашего сайта видит Поиск Google, топ-10 страниц какого-нибудь сайта, топ-10 всех запросов, ограниченных по платформе и/или региону и многое другое.

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


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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.