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

Эта мысль красной нитью пойдет сквозь материал под катом, и она, пожалуй, требует пояснения. Статья основана на докладе Николая Алименкова, к которому он подошёл не просто прогретым, а горящим после дискуссии с Алексеем Виноградовым о подходах к написанию тестов: методом прямого кода или при помощи паттернов. Нужны ли какие-то еще паттерны, кроме PageElement, Steps, PageObject?! С чего кто-то решил, что паттерны усложняют код, заставляют нас тратить время на создание ненужных (?) boilerplate-простыней? SOLID вам не угодил? А ведь все они создавались с учётом всего накопленного опыта сообщества разработчиков и они знали, что делают.

Николай xpinjection Алименков – известный Java-разработчик, Java техлид и delivery-менеджер, основатель XP Injection. В настоящее время является независимым разработчиком и консультантом, Agile/XP коучем, спикером и организатором различных конференций

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



В основу этого материала легло выступление Николая Алименкова на конференции Heisenbug 2017 Piter под названием «Паттерны проектирования в автоматизации тестирования». Слайды здесь.


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

Но сначала – краткое определение паттернов проектирования.

Что такое дизайн-паттерн (Design Pattern), зачем эта штука существует?  

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

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



Проблем в автоматизации проектирования и разработке множество, и сталкиваясь с этими проблемами, люди формулировали паттерны. Изначально классические паттерны были сформулированы давным-давно четверкой, которая выпустила книгу Design Patterns.
В книге сформулированы все паттерны, с которыми они сталкивались в то время в объектно-ориентированном мире. Есть проблема – есть ее решение, и долгое время эта концепция дизайн-паттернов росла и развивалась, пополняясь новыми паттернами.

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



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

Большая часть этих факторов находится под влиянием разделения концепции: в любом вашем тесте – функциональном, интеграционном, unit-тесте — всегда присутствует три компонента: тестовая логика, тестовые данные и application driver, или technical details, technical parts – часть, отвечающая за непосредственное взаимодействие с вашим приложением, вашим кодом (вызов функций, клики на экран и т. п.).  

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

Все паттерны я разделил на несколько групп.

Структурные паттерны – Structural Patterns

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



Первая группа таких паттернов – это Page Object. Зачем он нужен, какова проблематика?
Первая часть проблематики: у нас есть логическая структура нашего приложения, и когда мы пишем тесты в коде, мы не совсем понимаем, где именно мы сейчас находимся – мы же не видим UI непосредственно со своим тестом. Где я нахожусь после шага 15, на какой странице, какие действия могу там сделать, могу ли, например, после 15 шага вновь вызвать log in?  

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

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

Вот три проблемы, которые помогает решать Page Object. Если у вас только пара тестов, у вас нет этой проблемы – просто нет масштаба, на который вы можете это применить. Если у вас пять – десять – пятнадцать тестов, у вас эта проблема может быть и может не быть. Поэтому вы должны понимать, соответствует ли этот паттерн тому, что вы делаете.



Давайте быстро «пробежимся» по Page Object. У нас есть какая-то страница с какими-то элементами, неважно, чем вы их помечаете (в данном примере с помощью аннотаций @FindBy). Вы можете использовать любые аннотации, которые вам нравятся. Я вынес все элементы этой логической страницы в одно отдельное место, снабдив ее дополнительно доменными методами, которые теперь выглядят таким образом:  



Например, теперь у меня есть доменный метод registerAccount, я приведу туда userName и количество денег (amount), и благодаря этому в одно поле я ввожу имя, в другое поле ввожу количество денег, нажимаю кнопку и у меня создаётся новый аккаунт. Или, например, ввести первую букву имени (пример ниже).

Таким образом, тест выглядит очень просто, в тесте всего этого нет, оно вынесено, тестовая логика очистилась. Мы получили то, ради чего этот паттерн был придуман.
Это самый простой паттерн. Идем дальше.

Fluent/Chain of invocations

Следующая проблематика, которую вы хотите решить – когда вы вызываете что-нибудь, например, на login page. Можете ли вы далее вызвать что-нибудь на login page или нет? Вы не знаете.
Теперь представьте себе, что на какой-то странице у вас есть, например, 50 методов. И вы не понимаете, могут ли они все сразу вызваться, или можно вызывать только некоторые из них, а потом уже другие. К примеру, могу ли я работать с диалогом показа имен, если я еще не ввел никакой буквы и не вывалилась автоподсказка? Наверно, нет, потому что этого диалога пока как бы не существует.

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



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

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

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

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

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

Factory/Page Factory

Следующий паттерн – это Page Factory, или просто Factory, потому что он может применяться не только к страницам. Возник этот паттерн потому, что иногда, чтобы инициализировать вашу страницу, необходимо сделать больше действий, чем просто сказать «new page» или open, или еще что-то. То есть у вас в этой странице скрыта еще какая-то дополнительная логика, и вы хотите ее куда-то зарегистрировать, инициализировать ее элементы и так далее.

В этот случае вам бы хотелось, чтобы эта информация была скрыта от того, кто создает эту страницу, чтобы она была спрятана – это техническая информация, которая никому не важна.
Именно здесь применяется подход Factory. В данном случае у меня действует такой подход: я говорю «new MainPage», передаю туда драйвер и потом говорю «страница, откройся». Если бы я хотел сделать что-то дополнительное на этом открытии, мне нужно было бы либо занести это в метод open, который стал бы factory-методом, потому что он открывал бы эту страницу, инициализируя ее и делая ее новой, либо мне нужно было бы внести это в конструктор, что может быть тоже не очень хорошо.

Поэтому есть альтернативный подход – когда вы просто указываете вашу фабрику (я для примера привел здесь классическую Page Factory, которая есть в Java для web-драйвера), вы можете просто заказать Page Factory, Init elements, и у вас на выходе получится экземпляр класса этой страницы со всеми инициализированными элементами, которые есть в этой странице.

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

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

Page Element/Composite List of Items Link Menu Panel Checkbox

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

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

No duplicated code

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



Так появляется паттерн Page Element, который говорит, что вместо прежней страницы у нас будет улучшенная, на которую вместо полей name, amount и так далее вставляются высокоуровневые виджеты. Первый из них – это форма, которая умеет делать действия, характерные для всех форм, — такие как submit, «введи в поле значение», validate так далее, второй – табличка.

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



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

Loadable Component

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

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

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

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

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



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

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

В данном конкретном случае – на слайде выше есть стратегия по регистрации пользователя. Первая реализация этой стратегии использует для этого браузер – она открывает страничку и выводит поля, кнопку «зарегистрировать», получая ID на выходе из URL и возвращая нам объект юзера, а вторая идет через API.

Как вы думаете, какая быстрее?

Наверняка вторая: хочу ли я везде прописывать этот код руками, если я потом решил поменять его на 97%? Наверно, нет.

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

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

Паттерны данных – Data Patterns

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

Такова мотивация всех паттернов данных.

Value Object

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



Суть паттерна такова: если у вас есть несколько объектов, объединенных между собой логически (в данном примере есть registerUser, и мы передаем туда пять параметров – имя, фамилию, возраст, роль и прочее). Я лично видел методы, в которых делали около ста параметров, и спокойно с этим жили, насколько это было удобно – остается только догадываться. Параметры были логически указаны, но нигде этой связи указано не было.

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

Почему ValueObject? Он Immutable: после того, как он создается, его нельзя изменить, потому что в этом его задача, он служит для передачи данных из точки А в точку Б, а не для того чтобы быть модифицируемым или нести сторонние эффекты.

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

Builder

Следующий паттерн – это Builder. Предположим, у нас есть большой объект, и этот объект может быть сконфигурировано совершенно по-разному. Можно пойти первым способом и добавить столько конструкторов, сколько вариаций у вас есть, и каждый раз, когда вы встречаетесь с новой вариацией, вы можете добавлять новый конструктор. В итоге вы будете иметь 100500 конструкторов, и будет совершенно непонятно, когда какой вызывать.



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

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

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

Assert Object/Matchers

Следующий паттерн, о котором говорят все, но применяют его очень мало людей – это Assert Object, или «матчеры». У нас есть классический подход – мы вытащили пользователей и хотим сделать на них какие-то проверки. Классический подход отличается тем, что мы делаем множество различных проверок, и все они относятся к какой-то одной доменной сущности.
 


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

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

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

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

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

Data Registry

Следующий шаблон более интересен. Его проблематика такая: предположим, мы в тестах начинаем использовать данные, и для того, чтобы они были независимы друг от друга, пытаемся каким-то образом отвязать их друг от друга, но в результате можем прийти к тому, что получаются зависимые тесты, которые будут «знать» о логике друг друга. Например, этот тест будет знать, что он использует user 1,2,3, и после этого он говорит «все, user 1,2,3, закреплен за мной и больше никто его не использует», хотя кто-то может попытаться скопипастить его в другое место, не зная о такой проблеме.



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

Object Pool/Flyweight

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



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

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

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

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

Data Provider

Следующий паттерн – Data Provider, наверняка знаком всем. Если вы хотите сделать data-driven тесты, и хотели бы, чтобы одна и та же тестовая логика выполнялась с разными данными, для этого вы загружаете свои данные из какого-либо внешнего источника (в данном случае xls), либо из CSV, либо подтягиваете с какого-то сервиса, либо они у вас вшиты прямо здесь.



Это можно сделать либо вот таким корявым способом – под «корявым» я подразумеваю нетипизированные данные, которые представляют из себя простые структуры наподобие массив-массивов или массив-строк, либо же вы можете перейти на более современный подход, который позволяет вам работать на уровне Entity, или на уровне Value Object, про которые мы говорили.



В данном случае вы можете пометить свой метод с помощью аннотации dataProvider, это может быть ваша аннотация или G Unit 5, который позволяет реализовывать такую концепцию, и уже оттуда вернуть набор параметров для использования в тесте.

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

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

Technical Patterns

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

Decorator

Достаточно известный паттерн в этой области – Decorator. Если вы работаете с какими-либо техническими драйверами (web-драйвер или какой-либо еще) — и хотите добавить к нему, например, логирование или кэширование, или что-то еще. Но при этом ваши тесты не должны об этом знать. В этом случае сама логика теста остается прежней — меняется только техническая реализация.

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



Например, мы хотим после клика записывать куда-то в лог. Мы оборачиваем наш основной драйвер EventFiringWebDriver, регистрируем туда слушателя, и, соответственно, наши тесты об этом не знают – они как работали с интерфейсом web-драйвера, так и продолжают.
 
Для того, чтобы наши тесты действительно об этом не знали, здесь используется вспомогательный паттерн Factory, чтобы этого не было в самой тестовой логике. Чтобы тем, кому действительно нужен браузер, говорил «Factory, дай мне браузер», и ему выдавали браузер (или драйвер). Так же можно воспользоваться пулом и получить уже сконфигурированный браузер из него.   

Proxy

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



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



В данном случае самый популярный способ – это использование HTTP proxy для ваших тестов, который позволяет гибко настроить, например, black-листы, и сказать, что когда мое приложение пойдет в твиттер, фейсбук и так далее, я верну такие-то закэшированные результаты или верну ничего. Иногда это единственный способ, благодаря которому вы можете проверить, например, какое-нибудь exceptional-поведение ваших внешних сервисов.

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

Business Involvement Patterns

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

Keyword Driven Testing

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

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



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

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

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

Behavior Specification

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



В данном случае у нас очень простой сценарий: я говорю, что могу сложить два числа, я ввел 50 и 70 в калькулятор, и, нажав сложить и равно, я должен получить 120. Эти тесты не являются «тестами» в чистом виде, это уже более описание поведения, они понятны всем, но, опять же, – паттерн рассчитан на то, что ваш бизнес очень хочет быть вовлеченным в процесс тестирования, например, делать приемочные критерии в виде таких спецификаций, отслеживать, какие из них проходят.

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

Behavior Driven Development

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



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

Лично я считаю, что если Behavior Driven Development или концепцию Behavior Specification притягивают к unit-тестам или к интеграционным тестам, то это просто бесполезная трата времени.   

Steps

Концепция последнего на сегодня паттерна – Steps, интересна вне зависимости от того, используете ли вы Behavior Driven Development, Keyword Driven или Behavior Specification. Когда вы используете логически сценарий, он состоит из шагов. Когда вы реализуете его в коде, зачастую шаги теряются – появляются вызовы каких-то технических деталей, подготовка данных, еще что-то, и очень непросто среди этого вычленить шаги.



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

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

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



У вас есть Page Object или любая другая техническая реализация ваших тестов, и их нужно соединить, для чего и существуют Steps, реализующие логические составляющие ваших тестов.



Если вы задумаетесь над web-драйвер тестом в верхней части слайда, который написан в концепции Steps, в котором каждый шаг вызывается — он логический, его легко прочитать.

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

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



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

---

Если вам понравился данный доклад Николая Алименкова, спешим пригласить вас на его очередное выступление в рамках грядущей конференции Heisenbug 2017 Moscow, которая пройдет в Москве 8-9 декабря. На ней Николай расскажет о взаимодействии разработчиков и тестировщиков.
Вам также могут быть интересны и другие доклады, например:

• Truths about technical testing (Alan Page, Unity)
• Тестирование браузерной производительности web приложений  (Владимир Ситников, Netcracker)
• Инструменты тестировщика (Юлия Атлыгина, ALM Works)

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

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

bool *t = new bool[X][Y];
// много строк
switch (t[M][N])
{
case true:
        // много строк
        break;
case false:
        // много строк
        break;
default:
        // много строк
        break;
}

Сразу возникает вопрос: зачем нужна ветка default? Если переменная не равна true, то она равна false. Однокурсник сказал: «Для отладки». Думаю: что тут можно отлаживать? Но не всё так просто.

Запускаю. Выполняется код в ветке default. Самое первое предположение — забыли поставить break. Внимательно перечитываю код — всё в порядке. Запускаю в отладчике и замечаю, что выполняется сразу ветка default, а в ветку true или false даже не заходит. Решаю просмотреть значение переменной. Visual Studio 2012 запущенная на Windows 7 показывает 205. Допустим. Плюсы я стал учить недавно, поэтому решил провести небольшой опыт: создал булевую переменную и присвоил ей 205. Отрабатывает ветка true. Пока я размышлял над этой проблемой, однокурсник нашёл решение этой проблемы: оказывается, массив не был инициализирован. После инициализации проблема исчезла. Теперь у меня возник возник вопрос: неужели проблема в switch? Ради проверки я решил провести следующий опыт.

#include 
using namespace std;

int main() {
    bool *t = new bool[1];
    switch (t[0])
    {
    case true:
        cout << "true\n";
        break;
    case false:
        cout << "false\n";
        break;
    default:
        cout << "superposition\n";
        break;
    }
    if(t[0] == true) {
        cout << "true\n";
    } else if(t[0] == false) {
        cout << "false\n";
    } else {
        cout << "superposition\n";
    }
    if(t[0]) {
        cout << "true\n";
    } else if(!t[0]) {
        cout << "false\n";
    } else {
        cout << "superposition\n";
    }
    delete[] t;
    return 0;
}

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

Как создать такую переменную Шрёдингера? Создайте динамический или статический массив. Используйте его перед инициализацией. А также, самое вкусное, то, что вы можете скопировать это неопределённое значение, даже в скалярную переменную. Где это может пригодится — решать вам.

Интересно также то, что если перед проверкой вставить:

char a = t[0];
t[0] = a;

то переменная наконец-то станет true. А если написать

bool a = t[0];
t[0] = a;

то ничего не изменится.

Позднее я повторил опыт на Visual Studio 2013 с 5 пакетом обновления запущенная на Windows 7. Там отладчик говорит, что неинициализированная переменная равна true, но несмотря на это в блок true не заходит. Также она говорит, что ветка default не нужна, так как все возможные метки уже заданы. Но несмотря на это заходит в блок default.

В Linux данная особенность не проявляется.

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

Как понять качественно ли мы пишем?

Сколько слов вы видите за день? Верьте или нет, исследования показали, что типичный пользователь социальных сетей видит около 54 000 слов в день.

Черт, это больше слов, чем вы можете найти в книге! Например, “Бойцовский клуб”, один из моих любимых романов, содержит всего 49,962 слова.

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

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

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

Реакционные карты

Еще в 2002 году несколько человек из Microsoft создали метод тестирования, известный как Microsoft Response Card Method (метод реакционных карт от Майкрософт). Это способ измерить востребованность продукта, используя набор из 118 реакционных карточек.

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



Карты реакции

Изначально этот метод использовался для тестирования дизайна, но его также можно использовать для проверки слов в электронной почте, веб-сайте или даже в посте на Medium.

С помощью этого метода вы получите более качественный фидбэк, нежели чем если вы спросите “Вам это нравится?”. Он улавливает эмоциональную реакцию людей, используя контролируемую лексику. Ограничивая слова, которые люди могут выбрать, становится легче сравнивать и объединять результаты.

Если вы решите, что 118 карточек это слишком много, используйте меньшее количество. The Nielsen Norman Group рекомендуют использовать 25 слов или меньше.

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

Выделение текста

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

В конце концов мы можете получить что-то подобное:



Кодированный цветом материал

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

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

Стикеры

Черт возьми, я люблю стикеры. Это просто маленькие кусочки клейкой бумаги, но я клянусь, они обладают магической силой! Возьмите любой старый документ, прикрепите к нему любой глупый стикер и БАМ! Этот документ теперь источает веселье.

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

Маркеры это круто, но вы ограничены по количеству цветов, которые вы можете использовать. Если вы используете более 2 или 3 цветов, то может быть трудно вспомнить, что означает каждый цвет. (Подожди, давай снова, что означает желтый?)

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

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

• = Этот отрывок не имеет никакого смысла
• = Этот отрывок был познавательным
• = Этот отрывок был пугающим
• = О, этот отрывок был настолько ужасным, что у меня болит сердечко

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

Объясните это другу

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

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

“Как бы ты объяснил это своему другу?”

По сути вы просите их повторить то, что они только что прочитали, но своими словами. Теперь внимательно слушайте, что они говорят.

Если они объясняют тему, используя те же самые слова, которые вы написали, скорее всего ваши слова отложились у них в голове—и это хорошо. Ваш посыл сработал!

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

В книге Made to Stick Чип и Дэн Хит говорят, что идея должна иметь эти 6 характеристик для того, чтобы быть запоминающейся:

• Простой: понятна ли суть?
• Неожиданной: завоевывает ли это внимание людей?
• Конкретной: достаточно ли она конкретная, чтобы можно было вспомнить её позже?
• Достоверной: можно ли ей верить?
• Эмоциональной: вызывает ли она у людей чувство озабоченности?
• Содержательной: побуждает ли она людей к действиям?

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

Выберите лучшую версию

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



Вопрос, который я задаю себе каждый день

Что если бы был способ проверить две или три версии и позволить читателям выбрать их любимую версию? Именно в этом вся суть этого метода.

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

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

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

Метод похож на тестирование типа A/B, но в гораздо меньшем масштабе. Однако в отличие от тестирования A/B, этот метод помогает понять, почему кто-то предпочитает одну версию другой. К тому же он помогает вам в процессе написания. Тестирование типа A/B обычно происходит, когда материал уже написан.

Время проверки

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

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

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

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

• Проверка контента — Анжела Колтер
• Простой метод для оценки содержания — Пит-Гейл
• Когда следует перейти к тестированию контента? — Сара Заскес Уолш
• Практические советы по тестированию контента на сайтах — Hoa Лоранджер

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

Сегодня вы можете увидеть более 50 000 слов. Надеюсь, эти 1500 слов стоили потраченного вами времени.

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

Mars Information Services: добро пожаловать в Марс!

Мы начинаем серию публикаций о том, как устроена и работает IT-поддержка глобальной американской компании Mars Incorporated, которая ведет свою деятельность почти в 80 странах и является одним из мировых лидеров по производству продуктов питания. Добро пожаловать в блог Mars Information Services (Mars IS).

Цифровая составляющая шоколадного батончика

В России Mars работает с 1991 года. Сегодня у компании десять фабрик в четырех регионах страны, а головной российский офис с 1996 года располагался в подмосковном городе Ступино, а 2016 — переехал в Москву, на Ленинградский проспект. Кроме кондитерской фабрики и предприятия по производству кормов для домашних животных в Ступино базируется российское подразделение Mars IS. Это один из семи мировых IT-хабов компании.

Mars IS отвечает за IT-решения и инфраструктуру всех офисов и фабрик компании Mars. Наша команда – это полторы тысячи специалистов по всему миру, в том числе, около 200 — в Ступино. К слову, многие из них могут работать из дома, по согласованию с руководством. Наши российские сотрудники в Ступино обеспечивают технологическое лидерство, благодаря которому производительность компании увеличивается, а взаимодействие и эффективность всех сотрудников Mars — улучшается.

Наши специалисты работают практически во всех сферах IT: телекоммуникации (включая IP-телефонию), бизнес-приложения, персональные компьютеры и серверы, мобильные устройства, центры обработки данных, инфраструктурные технологии (Unix, Linux, Windows, Oracle), разработка, поддержка и внедрение IT-решений. В Mars IS создана высокопрофессиональная команда по внедрению и поддержке SAP.

Все внутренние процессы соответствуют передовым международным индустриальным практикам. Сервисная работа ведется по стандартам ITIL, что позволяет быть уверенными в качестве всех предоставляемых услуг. Для своих проектов компания использует общепринятые методологии: Prince2, Waterfall, Scrum. Кроме того, сотрудники нашей команды обладают опытом работы в поддержке инфраструктуры или бизнес-приложений, а также знаниями основных практик управления IT – ITIL, COBIT, Lean IT, MOF и других.
suglosta

Основные направления нашей работы

В Mars IS три основных направления по управлению: управление внедрением, услугами и взаимоотношениями с бизнес-подразделениями компании.
Команда управления внедрением отвечает за координацию работ по установке нового программного и аппаратного обеспечения. А также ответственна за ввод в эксплуатацию новых процессов, оборудования, программного обеспечения, документации. Крупнейшим проектом отдела является внедрение приложения SAP на территории СНГ.

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

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

Наш главный капитал – люди, работающие на производстве

В рамках процесса Business relationship management сотрудники отдела регулярно встречаются с руководящим звеном бизнес-подразделений Mars и обсуждают возникающие проблемы, связанные с используемыми в данных подразделениях IT-решениями.

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

Процесс Business continuity management отвечает за непрерывность IT-поддержки бизнес-структур компании. Это комплексный подход, направленный на определение потенциальных угроз, анализ их влияния и регулировку процессов восстановления после сбоев.

Примеры проектов, которые были внедрены данным подразделением:

• автоматизация работы складских инспекторов с применением технологий SalesForce и мобильного приложения для платформы iOS;
• создание центра разрешения вопросов, связанных с работой отдела логистики с применением технологий SalesForce;
• внедрение сервиса электронного документооборота (через EDI) для обмена счетами-фактурами с крупными торговыми сетями;
• разработка и внедрение системы для сбора и управления промо-активностями Collaborative Activity Management system;
• разработка и внедрение системы прогнозирования распределения продукции по складам — Demand 2 Supply.

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

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

Герои сериала «Шерлок»

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

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

В команде локализации Badoo всего лишь два разработчика, но мы держимся и создаём очень интересные инструменты:

• Translation Memory
• Collaborative Translation Platform, доступной по адресу https://translate.badoo.com/,
• функционал предоставления корректного перевода конкретному пользователю (в зависимости от языка, пола, склонения, числа),
• система подготовки переводов для A/B-тестирования (да, мы проводим тестирование вариантов перевода, чтобы определить, какая формулировка лучше),
• десяток интерфейсов для работы переводчиков,
• сбор статистики по работе переводчиков и использованию ими инструментов.

Перечисленные инструменты призваны помочь в процессе локализации сайта Badoo, двух мобильных приложений Badoo (для Android и iOS), а также партнёрских приложений Chappy, Bumble, Huggle, Hot or Not на 47 языков. Это огромный фронт работ.

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

Процесс перевода выглядит так:

1. Дизайнеры рисуют.
2. Программисты программируют.
3. Переводчики переводят.
4. Релиз.

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

По нашей задумке, процесс должен выглядеть так:

1. Дизайнеры рисуют.
2. Программисты программируют, а переводчики – переводят и могут каким-то способом сразу видеть результат.
3. Релиз.

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

Наши дизайнеры работают в графическом редакторе Sketch. Мы выяснили, что идущая вместе с ним утилита sketch-tool умеет генерировать скриншоты, а это значит, при добавлении перевода есть возможность сразу показывать скриншот переводчику! Но возник вопрос: как заменить исходные тексты в дизайне, чтобы получить локализованный скриншот?

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

Давайте разберёмся, как устроен .sketch-файл изнутри.

Представление данных внутри .sketch-файла

В 43-й версии Sketch разработчики стали использовать новый формат .sketch-файла для «лучшей интеграции со сторонними сервисами».

Логически в подготовленном в Sketch дизайне выделяются Pages, Artboards и графические элементы. Каждой сущности – Pages, Artboards и графическим элементам – один раз (в момент создания) присваивается уникальный идентификатор (UUID), который впоследствии не меняется.

Схематично связи между сущностями можно изобразить так:

Смотрите картинку ниже, чтобы понять, что есть что в интерфейсе Sketch: iPhone SE и iPhone 7 – две из возможных Artboards, a Page 1 – это одна из возможных Pages.

Сохранённый в .sketch-файл дизайн представляет собой ZIP-архив, внутри которого находятся директории с PNG- и JSON-файлами. Выглядит просто?

Если мы разархивируем .sketch-файл, то дерево директорий получится примерно таким:

Информация о каждой Page и связанных объектах Artboard хранится в pages/*.json. Именем файла служит UUID объекта Page, каждому объекту Page соответствует один файл.

Мы можем запросто открыть любой pages/*.json и отредактировать, например, название одного из Artboards. Чтобы определить конкретный файл для редактирования, запускаем:

$ grep -l ‘iPhone 7’ pages/* 

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

…смерть его на конце иглы, та игла в яйце, то яйцо в утке, та утка в зайце, тот заяц в сундуке, а сундук стоит на высоком дубу...
«Царевна-лягушка»

Текст на кнопке упакован в бинарный plist, закодированный в строку Base64, являющуюся значением атрибута сериализованного JS-объекта, находящегося в одном из файлов, сжатых ZIP-ом.

Не будем касаться вопросов разархивирования и чтения JSON из файлов, но стоит сказать о формате Property Lists (bplist на схеме выше). Чтобы модифицировать текст «Нажми меня», можно использовать утилиту plutil. Она позволяет вставить новое и удалить старое значение некоего свойства, а ещё с её помощью можно преобразовать plist из бинарного вида в XML и обратно. XML – удобный формат, для работы с ним существует множество инструментов. Также возможен экспорт в JSON, но, во-первых, при этом происходит потеря типов данных, а во-вторых, не всегда plist может быть сконвертирован в JSON. Например, с plist-ом из .sketch-файла экспорт в JSON не сработал.

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

Выбор подходящей реализации

Вариант 1. Ленивое решение

Мы пытались рассказать переводчикам про JSON, Base64 и bplist, научить их самостоятельно заменять тексты переводами и делать скриншоты. Но когда им показали консольную команду экспорта превью

$ sketchtool export artboards --items='42C53146-F9BF-4EEE-A4F8-BB489F0A3CDA,BF38A95A-F0CD-452E-BE26-E346EBD349CE' --formats=png --save-for-web example_design.sketch

поняли, что этот вариант не годится.

(Шутка, ничего переводчикам мы не рассказывали, а сразу перешли ко второму варианту).

Вариант 2. True way

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

Для этого мы решили разработать сервис, минимальным функционалом которого стало бы:

1. Определение в .sketch-файле UUID графических элементов, содержащих текст.
2. Генерация скриншотов с локализованным текстом.

Проект получил название Sketch Modifier и был опубликован на GitHub.

Работа со Sketch Modifier

Чтобы начать использовать Sketch Modifier, нужно установить Node.js. на macOS (где конечно уже должен быть установлен Sketch https://www.sketchapp.com/). Да, Sketch есть только под macOS. Но если ваш дизайнер работает в Sketch, то как минимум один Mac у вас есть.

Рассмотрим процесс работы со Sketch Modifier по шагам.

Шаг 1. Установка

Находите компьютер под управлением macOS. Скачиваете и устанавливаете на него Node.js, что совсем просто.

Далее скачиваете архив или клонируете репозиторий с GitHub командой

$ git clone https://github.com/AlexTimin/sketch-modifier.git

Переходите в директорию проекта

$ cd sketch-modifier

Устанавливаете зависимости с помощью npm:

$ npm install

И, наконец, запускаете сервер

$ ./bin/www

Всё, теперь по адресу http://localhost:3000 у вас должен отзываться сервер. Можете перейти по этому адресу в браузере и проверить.

Шаг 2. Загрузка .sketch-файла и определение исходных текстов

Для примера возьмем example_design.sketch и загрузим его в систему. Для этого нужно отправить запрос из директории, в которую вы сохранили example_design.sketch:

$ curl -F 'data=@example_design.sketch' http://localhost:3000/add-sketch/

.sketch-файлу будет присвоен UUID. В ответ вы получите JSON следующего вида:

{
    "8a2009c5-36ca-4328-87d6-16aa0c2e2800": {  // присвоенный example_design.sketch UUID, у вас он будет другой
        "5A0F429A-C974-460A-9482-93AED7456850": {  // Page 1 UUID
            "C1C29749-B967-494D-8D7E-A484EAB37534": {  // iPhone SE Artboard UUID
                "E335D359-9DF3-4DCC-8B79-E77E38824714": "Нажми меня" // UUID текста на кнопке
            }
            … // информация по другим Artboards
        }
        … // информация по другим Pages
    }
}

Можете сохранить эти данные себе в базу, отправить в /dev/null или сделать ещё что-нибудь интересное. Но мы сохраняем их в базу.

Шаг 3. Генерация переведённых превью

Чтобы заменить текст, нужно отправить запрос на адрес http://localhost:3000/generate-preview/ с указанием параметров screens и textReplaces. Список необходимых команд будет ниже, а пока разберёмся со структурой параметров запроса.

В параметре screens мы указываем список UUID тех Artboards, скриншоты которых хотим получить. Значение параметра имеет такую структуру:

{
    Example Design UUID: [  // example_design.sketch
        Artboard UUID,  // iPhone SE
        ... 
    ]
}

В textReplaces мы указываем UUID текстовых элементов и новый текст. Значение параметра имеет такую структуру:

{
    Text UUID: "новый текст, перевод",
    ...
}

Итак, формируем запрос для генерации скриншота. Заменим текст «Нажми меня» на «Start the party!», например. Для этого нам понадобится файл generate-preview-request-data, в котором мы укажем значения параметров запроса.

Содержимое файла generate-preview-request-data:

textReplaces={
    "E335D359-9DF3-4DCC-8B79-E77E38824714": "Start the  party!"
}&screens={
    "8a2009c5-36ca-4328-87d6-16aa0c2e2800" : [
        "C1C29749-B967-494D-8D7E-A484EAB37534"
    ]
}

Выполняем команду из директории, в которую вы сохранили файл generate-preview-request-data.

$ curl -X POST -d "@generate-preview-request-data" http://localhost:3000/generate-preview/

В ответ вы получите скриншоты в Base64. Структура ответа будет такая:

{
    "C1C29749-B967-494D-8D7E-A484EAB37534": "data:image/7HYUIY786GFFDASeY+...;base64", 
    ...
}

Наверное, вы догадались, что ключом в структуре ответа является UUID запрошенного скриншота, а в значении записано представление скриншота (напомню, мы запрашивали скриншот для iPhone SE) в Base64.

Если вы сохраните, допустим, в example.html следующий код с подставленным Base64-представлением картинки

а потом откроете example.html в браузере, то увидите переведённый скриншот:

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

Заключение

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

Исходный код реализации находится на GitHub.

Пользуйтесь, советуйте способы усовершенствования, пишите отзывы.

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

Конференция Ignite в самом разгаре, а мы, тем временем, решили собрать воедино самые интересные новости этого события: Azure Trial доступен теперь на 1 год, новый язык программирования для квантовых компьютеров и три утилиты для работы с машинным обучением. Было интересно, приглашаем под кат узнать про эти и остальные новости. Будет много полезных ссылок.



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

Microsoft Azure

1. Если у вас возник вопрос: «Что это за символ на картинке выше?» Всё просто. Это новый логотип Microsoft Azure.
2. $200 кредитов в облаке, 1 год триала и бесплатные ресурсы на год здесь.
3. Azure Pass-Through Authentication теперь в статусе GA (General Availability), ранее она находилась в режиме предварительного доступа. Azure Pass-Through Authentication позволяет выполнять проверку подлинности в on-premis Active Directory без необходимости создания высокодоступной инфраструктуры ADFS.
4. В июне Microsoft приобрела Cloudyn, и теперь она становится бесплатной — для всех подписчиков Azure. Это решение для управления затратами, которое позволяет администраторам Azure определять, куда идут деньги, и как оптимально оптимизировать стоимость. Подробнее о Azure Cost Management можно узнать здесь.
5. Анонсирован Azure File Sync Preview. Это решение для синхронизация файлов между локальными серверами Windows и Azure File Shares.
6. Поддержка Powershell в Azure Cloud Shell, включая интеграцию в мобильное приложение.
7. Azure Service Fabric on Linux переходит из preview в GA (General Availability). Это платформа микросервисов и оркестрации, которую анонсировали ещё на Microsoft Build.
8. Для разработчиков компания выпустила три новых инструмента: Azure Machine Learning Experimentation, Azure Machine Learning Workbench и Azure Machine Learning Model Management. Azure Machine Learning эксперименты теперь можно запускать локально, переносить в Docker или в Azure, использовать различные фреймворки для глубокого обучения (Microsoft Cognitive Toolkit, Tensorflow, Caffe2, PyTorch и Chainer) и использовать кроссплатформенного клиента AML Workbench (Windows и Mac).
9. Кроме этого, в блоге Microsoft Azure были анонсы о новых типах виртуальных машин M-серии, доступности виртуальных машин серий Fv2/NCv2/ND с CPU Scalable Xeon от Intel и GPU NVIDIA Tesla P100 и P40, Azure Enterprise NFS Service совместно с NetApp, Azure DDoS Protection в preview версии, Azure Data Box (для переноса больших наборов данных в Azure) и Azure Migrate Service для переноса нагрузок в Azure.
10. Azure Stack расширяет список партнеров для поставки оборудования: Dell EMC, HPE, Lenovo.
11. Новые возможности для мониторинга и аналитики в Azure.
12. Три новых сертификационных экзамена Azure: Azure Stack (70-537), Linux Workloads on Azure (70-539) и Azure DevOps (70-538).

Microsoft 365, Windows, Windows Server

1. Microsoft 365 расширяется Microsoft 365 Firstline (F1) (бывший Kiosk) и Microsoft 365 Education, а также включает в себя Windows 10, Office 365 и Microsoft Enterprise Mobility + Security.
2. HP, Lenovo, Acer и Fujitsu начинают предлагать новые устройства Windows 10 S стоимостью от $275.
3. Windows Autopilot теперь поддерживает Surface устройства. Lenovo и HP получат поддержку в начале 2018, Fujitsu/Toshiba/Panasonic в конце 2018 года.
4. В Microsoft Intune появляется поддержка PowerShell скриптов для запуска на управляемых устройствах, а это открывает широкие возможности для управления.
5. Сессия "Microsoft 365: Modern management and deployment" полностью раскрывает концепцию о «modern IT» от Microsoft и будущее гибридных сценариев System Center Configuration Manager и Microsoft Intune.
6. Обновленный Windows Configuration Designer (WCD) доступен в Windows ADK и Windows Store.
7. Windows Server 1709 (Semi-annual Release) доступен для скачивания.

SQL и Power BI

1. Доступен SQL Server 2017. Одновременно для Windows, Linux и Docker контейнеров.
2. И бесконечный список небольших обновлений, изменений и новых функций для Power BI.
3. Azure SQL Database теперь совместима с SQL Server на 100%.

Office, Office 365 и SharePoint

1. Забегая вперед: во второй половине 2018 года мы увидим Microsoft Office 2019 и обновление всей линейки офисных продуктов, от клиентских до серверных приложений: Word, Excel, PowerPoint, Outlook, Exchange, SharePoint, Skype for Business.
2. Office 365 получает multi-geo в preview, что позволяет компаниям охватить услуги Office 365 (Sharepoint, OneDrive) в разных географических регионах центров обработки данных.
3. Обновлена панель приложений на Office.com
4. Microsoft Flow получает несколько обновлений, таких как более глубокая интеграция SharePoint и упрощенная совместная работа в SharePoint.
5. Теперь термин Unified Communication переходит в Intelligent Communication. Skype for Business остается, он даже получит обновление в 2018 году, но на Microsoft Ignite 2017 было много слов о "трансформации коммуникаций и объединении вместе всех бесед, встреч, файлов, приложений Office, сторонних интеграций и предоставлении единой точки входа для совместной работы в Office 365".
6. Очень большое демо можно посмотреть на сессии "Microsoft 365: Transform your communications with Microsoft Teams and Skype for Business".
7. OneDrive получает обновленный интерфейс, поддержку DRM (Digital Rights Management) и много всего ещё.
8. Новый SharePoint Admin Center появится в 2018 году. Получить доступ к preview можно уже сейчас.

Записи сессий с Microsoft Ignite 2017 можно найти здесь.

Об авторе

Антон Мосягин — системный инженер в Rambler&Co, ведёт канал в Telegram с заметками для ITpro и свой блог.

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

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

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


Это ты, хакер фронтенда

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

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

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

Часть 1. Поехали.

---

Почему веб должен умереть

Веб-приложения. На что они похожи, а? Я могу перечислить кучу их проблем, но давайте остановимся на двух.

1. Веб-разработка медленно повторяет 1990-е годы.
2. Веб-приложения невозможно защитить.

Вот хороший пост по Flux, последнему модному веб-фреймворку от Facebook. Автор обращает внимание, что Flux воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году. Microsoft использовала эту модель, потому что она подходила для медленных компьютеров, но под неё было настолько неудобно программировать, так что не прошло и десятилетия, как выросла целая экосистема продуктов (вроде OWL), позволяющих абстрагироваться над лежащей в основе системой сообщений WndProc.

Одна из причин, почему React/Flux работают таким образом — очень медленные движки веб-рендеринга. Это правда, и конечный видимый пользователю результат лишь немного более замысловатый, чем пользователь Windows мог видеть 20 лет назад:


Windows 98

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



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

Но Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти, в то время как Google Docs со скриншота использует CPU на 2,5 ГГц и почти в десять раз больше памяти.

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

• Визуальный редактор UI с ограничениями макета и привязкой данных.
• Продвинутая поддержка программных компонентов на многих языках. Вы могли смешивать статически типизированный нативный код и языки сценариев.
• Выпускаемые исполняемые файлы были настолько эффективны, что работали на нескольких мегабайтах RAM.
• Поддержка построения графиков, тематизации, 3D-графики, программирования сокетов, интерактивной отладки…

Многие из этих функций появились на веб-платформе только в последние несколько лет, и часто весьма поверхностно. Веб-приложения не могут использовать реальные сокеты, так что вместо этого серверы приходится переводить на поддержку «веб-сокетов». Такие базовые вещи как компоненты UI — это тихий ужас. Не существует серьёзной Web IDE, а насчёт смешивания разных языков программирования… ну, вы можете попытаться всё скомпилировать в JavaScript. Иногда.

Разработчики любят писать веб-приложения по одной причине — ожидания пользователей от таких приложений исключительно низки. От приложений для Windows 95 вы ожидаете наличия пиктограмм, перетягивания мышкой, отмены произведённых действий, ассоциаций с расширениями файлов, нормальных сочетаний «горячих клавиш», полезной деятельности в фоновом режиме… и даже работы в офлайне! Но это самые простые приложения. По настоящему крутой софт мог встраиваться в документы Office или расширять функциональность Explorer, или допускать расширение функциональности произвольными плагинами, которые изначально неизвестны автору программы. Веб-приложения обычно не делают ничего подобного.

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

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

Веб-приложения невозможно защитить

В конце 1990-х ужасная реализация ЯП нависла над программной индустрией: уязвимости безопасности в программах C/C++ перестали быть редкими ошибками, которые можно исправить по отдельности. Они появились повсюду. Люди стали понимать, что если код C/C++ выставить в интернет, неизбежно появятся эксплоиты.

Можно оценить невинность того мира, если почитать отчёт SANS по сетевому червю Code Red от 2001 года:

«Представители Microsoft и агентств безопасности США провели пресс-конференцию, где инструктировали пользователей скачать патч с сайта Microsoft и назвали „гражданским долгом” скачивание этого патча. CNN и другие новостные издания после распространения Code Red предупредили пользователей о необходимости установить патчи на свои системы».

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


Первые признаки заражения Blaster

Постепенно индустрия начала меняться, но с криками и протестами. В то время пользователи Linux и Mac частенько говорили, что это вообще чисто проблема Microsoft… а их системы созданы некими сверхпрограммистами. Так что в то время как Microsoft приняла факт, что столкнулась с экзистенциальным кризисом и ввела «жизненный цикл безопасной разработки» (гигантская программа переобучения и новый процесс), её конкуренты практически бездействовали. Редмонд добавил файрвол в Windows XP и выпустил сертификаты для подписи кода. Мобильный код запретили. Когда стало ясно, что уязвимости в безопасности идут бесконечным потоком, ввели периодический выпуск патчей “Patch Tuesday”. Умные хакеры продолжали делать открытия, как эксплуатировать известные ранее баги, которые казались безопасными, и как обходить защиты от эксплоитов, ранее казавшиеся надёжными. Сообщества Mac и Linux начали постепенно выходить из спячки и осознавать факт, что они не являются волшебным образом защищёнными от вирусов и эксплоитов.

Последним поворотным моментом стал 2008 год, когда Google выпустила Chrome, важный проект с той точки зрения, что они потратили массу усилий на создание сложной, но совершенно незаметной песочницы для движка рендеринга. Другими словами, лучшие в индустрии разработчики признали, что они не способны написать безопасный код C++ независимо от того, как упорно будут над ним работать. Такой тезис и изолированная архитектура стали стандартами де-факто.

Пришла очередь веб-платформы

К сожалению, веб не вывел нас на благословенную землю безопасных приложений. Хотя веб-приложения в каком-то роде изолированы от материнской ОС, и это хорошо, но сами приложения вряд ли более надёжны, чем код Windows от 2001 года. Вместо того, чтобы навсегда избавиться от доставшихся по наследству проблем, веб просто заменил один тип переполнения буфера другим. В десктопных приложениях эксплуатировались уязвимости типа двойного освобождения одной и той же памяти (double free), уязвимости целостности стека (stack smash), использования памяти после освобождения (use after free) и прочие. Веб-приложения исправили их, но представили собственные такие же ошибки: инъекции SQL, XSS, XSRF, инъекции заголовков, смешение типов MIME и так далее.

Всё это ведёт к простому тезису:

Невозможно написать безопасное веб-приложение.

Не будем педантами. Я не говорю буквально обо всех веб-приложениях. Да, можно написать безопасный HTML Hello World, флаг в руки.

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

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

Для исправления вы можете сделать несколько изменений. Любое из этих изменений предотвратит ныне возможные атаки, но если добавить несколько уровней защиты («глубокая защита»), вы защититесь от того, что какой-то из уровней не сработает в случае уязвимостей в браузере, которые найдут в будущем. Во-первых, используйте токен XSRF, как обсуждалось ранее, это гарантирует, что результаты JSON с конфиденциальными данными возвращаются только для ваших страниц. Во-вторых, ваши страницы ответа JSON должны поддерживать только запросы POST, чтобы предотвратить загрузку скрипта через тег

В инженерной части, конечно, всем. Список отличий примерно такой же, как у паровоза и апельсина. А вот в части интерьера — минимально. Разве что нет фасадов, нет заполнения наружных проёмов, много уникальных дверей из нержавейки. До КРОК я работал в проектной команде Инжпроекта из 25 человек по 4 станциям, уже новым, то есть достаточно ужатым в плане бюджета. Расскажу на примере «Румянцево», где я отвечал за интерьер.

У нас в ИТ-компании образовалась команда архитекторов, и поэтому нам часто задают такие вопросы. Постараюсь ответить на этот и ещё пару частых.

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

Вводные

Итак, на входе нашего «коттеджа» — картинка с концепцией от директора метрополитена или главного архитектора города (надо попасть максимально близко к ней по внешнему виду, но в ней не особо много деталей), куча нормативов (самые важные — пожарные), техзадание (с указанием типов материалов) и ещё немного вводных. С точки зрения модели BIM — есть голый объём в железобетоне, который надо заполнить. Конечно, в реальности он, скорее всего, ещё не создан, но в модели проектирования мы заполняем именно его.

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

1. Разбивка на помещения

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

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


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

Моя первая задача — «нарезать» станцию на помещения. Это отдалённо напоминает трассировку платы: есть много вариантов размещения, но нужно выбрать один из оптимальных. Задача усложняется тем, что по ходу работ требования могут немного меняться. Например, на «Румянцево» постоянно приходилось корректировать, потому что возникали требования по новым отверстиям — работа архитектора, конструктора, инженеров. В конце работы получаются помещения с атрибутами, полная разбивка с площадями.

Эта разбивка показывается смежникам, отвечающим за эксплуатацию станции. Они в ответ присылают замечания и пожелания в духе «прошу увеличить венткамеру до 25 квадратных метров, сейчас воздуха не хватает на удаление». Пожарные могут отметить: «здесь надо поставить пожарную преграду или противопожарную завесу». Кстати, да, в отличие от коттеджа, станции метро очень тщательно защищаются от пожара: опыт Лондона и других городов показал, насколько это важно. Из того, что обычно не знают пассажиры — то, что на эскалаторах предусматриваются специальные негорючие шторы: они падают и отсекают эскалатор от платформы как раз для того, чтобы не создавать вот этот поток воздуха. Крепления штор можно увидеть на входе на платформу. Некоторые принимают их за гермозатворы или фрагменты дверей бомбоубежищ со времён Второй Мировой, но это не так, конечно.

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

2. Задаём отделку

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

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

Затем начинаются параллельные процессы. Свет, отделка. Со светом особенности такие: помещение платформы довольно большое, и нужно просчитывать свет очень тщательно. Мы используем специальный софт для моделирования освещения, позволяющий учесть рассеивание, отражение от разных материалов и так далее. Считается он побыстрее, чем распространение звука для стадионов или храмов, конечно (https://habrahabr.ru/company/croc/blog/171147/, habrahabr.ru/company/croc/blog/241305). Выглядит это вот так:



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

С материалами отделки по деталям дольше всего на этом этапе. Считаем, например, потолочные панели, считаем пол, стены. Отправляем запросы поставщикам. Про пол — известно, например, из норматива и ТЗ, что это должен быть очень износостойкий материал (миллионы людей за месяц по нему будут ходить), поэтому подходит только натуральный камень. Предположим, это гранит. Мы смотрим, как можно уложиться в концепцию дизайнера и подбираем материал под задумку. Предположим, решили, что гранит у нас будет «сибирский светлый». Дальше начинаются запросы производителям — кто, почём и как быстро изготовит нужное число плит. Один производитель присылает, что может сделать как надо, плиты метр на метр, но дорого. Второй говорит — будут 500х500 мм, но сильно дешевле. И так далее. Размеры плит в процессе выбора поставщика могут меняться.

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

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

3. Инженерные подсистемы

Этот этап — самый затратный по времени, потому что состоит из постоянных переделок. Нужно согласовать десятки подсистем (слаботочку, пожаротушение, вентиляцию и так далее) так, чтобы всем смежникам всё понравилось. Если смежник хочет правку, мы корректируем. Мои коллеги тут многое описали.

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

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

Ещё детали

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

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

Ещё частые вопросы

Итак, мы занимаемся проектированием в BIM-среде, и у каждого — своя специализация. Давайте немного расскажу про другие частые вопросы коллег и про них самих.

Вот наша команда:



Родион Белов — главный архитектор компании КРОК.



Александр Скрыпник — архитектор, BIM-менеджер.
Юрий Яковлев — инженер, BIM-мастер.
Я — Роман Степанов – инженер, BIM-мастер.
Александр Апханов – инженер, BIM-мастер.

Вот наши компьютеры:





Такие странные они потому, что внутри — игровые станции. Нам они нужны для расчётов. Вот спека моей машины:









Мой коллега Александр работал в генплане Москвы (архитектурной мастерской Сергея Ткаченко, в творческой мастерской «Атриум»), участвовал в рабочке жилого комплекса «Символ» на территории завода «Серп и Молот». Стадию рабочего проектирования делали до гвоздя по LOD 400, коллеги потом даже модели шурупов расставляли.

Его спрашивают, что там особенного. Сформулировать сложно, потому что деталей очень много. Проект передовой по архитектуре в Москве, и даже не в плане внешнего вида, хотя это один из лучших жилых комплексов, а в плане приспособленности для жизни. 5 домов переменной этажностью от 5 до 27 этажей. Хорошая отделка мест общественного пользования — коридоры, лифты, фойе. Балконы от здания не отрезали (тот же Пик, например, заменяет балконы на подвальные кладовки, чтобы решить проблемы с инсоляцией – жильцы часто на балконе устраивают свалку хлама). Первые этажи общественного назначения: магазины, кафе, спортзал, соцкультбыт. Школа и детсад внутри комплекса. Весь район единой планировки. На первом этаже можно снять офис и сидеть работать. Главная цель — решаем проблему маятниковой миграции, чтобы можно было работать и делать всё нужное прямо около дома, как в компактных пространствах Швейцарии. Удобная среда. Внутри комплекса пешеходный бульвар, машины не заезжают.

Родион Белов — главный архитектор компании КРОК.
Наш идейный лидер, потомственный архитектор, окончил МАРХИ. До КРОКа работал в крупных архитектурных бюро в качестве ведущего архитектора и главного архитектора проекта. В КРОКе под началом Родиона реализованы такие проекты, как реконструкция Арбитражного Суда в Смоленске, проектирование одной из ОЭЗ, ЦОД за границей, BIM-модель офисного здания КРОК и даже проектирование инновационного города.

Юра — уникальный человек по скорости освоения BIM. Он очень плотно ушёл в работу с инженеркой. Именно он — тот человек, который творит чудеса на стадии согласования между смежниками. Говорит, BIM для этих задач просто идеален — на 2D-бумаге очень просто ошибиться, но в 3D можно размесить всё так, что даже очень тупой подрядчик не сможет сильно накосячить. Юре достаются довольно интересные решения. Больше всего он вспоминает короб, который обвился вокруг колонной змейкой — там на проекте главный архитектор согласовал троекратный перерасход материалов, лишь бы уместить все нужные системы. Нужно было обходить несущие конструкции здания, поэтому коммуникации закручивали вокруг элементов. Воздуховод и колонны — как удав обнял дерево.


Это не ошибка, а сложное проектное решение

Юра и Саша Апханов занимаются электрикой и СКС, слаботочкой, автоматикой. Наносят на схемы оборудование СКС, автоматики, безопасности — камеры, датчики и так далее, всё автоматизируют.

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

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

Ссылки

• Реконструкция здания суда в Смоленске: habrahabr.ru/company/croc/blog/323044
• Про инженерные подсистемы здания: habrahabr.ru/company/croc/blog/328140
• Озвучивание храма и стадиона: habrahabr.ru/company/croc/blog/171147, habrahabr.ru/company/croc/blog/241305
• Про BIM-среду проектирования – habrahabr.ru/company/croc/blog/335808
• Моя почта – RStepanov@croc.ru.

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

У нас в стране всё ещё бытует мнение, что человек должен овладеть какой-то профессией, и кормиться ею всю жизнь. Но эта самая жизнь сегодня меняется так быстро, что веками действующая схема работает всё хуже. Экономика оцифровывается, профессии исчезают, людей заменяют роботы и чат-боты. Поэтому сегодня всё труднее построить себе безбедное будущее, выбрав в молодости какое-то направление. Увы, но у нас пока не принято радикально менять профессию. И чем старше человек, тем труднее для него принять саму мысль, не то что решиться на это: «Как так, я уже 20 лет этим занимаюсь, опыт наработал, репутацию, а тут опять учиться, как школяру, и начинать с низов?». Да, решение непростое. Но чем сильнее экономико-технологические перемены будут влиять на занятость, тем актуальнее будет стоять вопрос смены профессии для всё большего количества людей. Но если человек сам хочет заняться чем-то новым, по желанию, а не из-за давления обстоятельств, то ему уже ничто не помешает.

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

Всем привет! Сейчас в России женщинам после 40 очень сложно искать работу. Может быть, моя история кого-то сподвигнет на активные шаги, или просто поможет в выборе новой профессии.

В 17 лет я окончила школу, и нужно было выбирать, куда идти учиться. Я совершенно не понимала, чем заняться. Это был 1991 год, рухнул Советский Союз, поэтому все шли туда, где платили деньги — на юристов и экономистов. Я поступила в екатеринбургский Институт народного хозяйства, на специальность «Коммерция», то есть стала учиться на экономиста. Окончив институт, десять лет работала в региональных банках. Потом был переезд в Москву, и снова банковская сфера. Моя работа в основном была связана с маркетингом, с продвижением продуктов, с рекламой. Например, писала рекламные брошюры по вкладам. Где-то с середины 2000-х стало ясно, что мир всё больше и больше уходит в сторону IT, в сторону software. И сегодня в любой индустрии важную роль играет софт. Так случилось и с моей профессией.

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



В 2007 году я впервые поехала отдыхать в США и буквально влюбилась в эту страну. По возвращении стала думать, что было бы классно поработать там, пожить какое-то время. Стала искать информацию, набрела на форум «Говорим про US», и там узнала про школу тестирования Михаила Портнова в Кремниевой долине. Начала смотреть записи на канале Михаила, где он часто рассказывал истории успеха своих студентов. Так началось мое знакомство с профессией тестировщика.

Я видела много успешных студентов Портнова, и чем больше было технической работы в моих проектах, тем чаще я задумывалась: «Чем я хуже? Я тоже могу работать в передовой технологии, востребованной по всему миру». Когда решение созрело, мне уже было 40 лет (сейчас 43), и чем я занимаюсь? Пишу рекламные брошюры! При этом в банк приходит работать молодежь, они очень энергичные, с хорошим образованием, у них свободный английский. А я хочу быть на плаву и иметь на руках какую-то профессию, которая меня будет кормить и в 50 и в 60 лет, и при этом хочу быть востребованной, заниматься интересным делом. А самое главное, я очень хотела работать в технологической индустрии, которая является пионером на рынке, чтобы я могла вносить какой-то вклад в изменение мира.

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

Первым делом прошла тренинг «Школа начинающих тестировщиков» Алексея Баранцева и его команды. Я всем его рекомендую, кто хочет приоткрыть для себя дверь в IT. Здесь вы встретите единомышленников, начнете развивать техническое мышление, получите азарт и мотивацию двигаться дальше. Далее я прошла тренинг «SQL для тестировщиков» от этой же команды. SQL — это must have для старта в тестировании.

По завершении проекта — это был апрель 2016 года — у меня было такое ощущение, что я уже просто гуру тестирования. Но на самом деле я ещё по уши была в маркетинге, рекламе, коммуникациях с клиентами. В тестировании я пока была новичком, да ещё и без технического образования. Была масса сомнений и вопросов, на которые нужно было ответить себе самой. Мне нужна была помощь, чтобы разобраться со всем этим. Я наняла себе карьерного коуча, Женю из Хьюстона (мы занимались по скайпу). Она помогла мне определиться:

• Уходить в IT или нет?
• Если да, то когда?
• Нужно ли получать второе высшее?
• Нужно ли мне идти в тестирование?
• Может быть, мне уйти в прожект-менеджмент?

Женя дала подсказку: «Если будешь уходить и искать работу с нуля, то упадешь в зарплате. Для тебя самый мягкий вариант — это попробовать из маркетинга перейти в IT в своём же банке. Будет меньше стресса, ты можешь сохранить свою зарплату, знаешь людей и окружение».

Я зашла на внутренний сайт банка и случилось чудо — была вакансия именно в отдел тестирования. Написала письмо начальнику отдела, приложила ссылку на свой профиль на LinkedIn. К тому времени мной была написана статья о тестировании для начинающих, на неё я тоже дала ссылку. Очень сильно переживала, как отреагирует Алексей, начальник отдела тестирования. Когда он всё это прочитал, то сказал: «Да. Случай интересный, очень нестандартный, потому что из IT в бизнес люди переходят, но чтобы из маркетинга в IT — это большая редкость». Мы поговорили, и он пригласил меня в свою команду. Я была просто счастлива, что в меня поверили. И сейчас уже год как я работаю в Quality Assurance (QA), в тестировании программного обеспечения, на должности тест-менеджера и UAT-координатора.

Новая профессия и учёба

Конечно, без технического образования в тестировании сложно. Нужно очень многому учиться, и учиться постоянно. Чтобы разобраться с новой темой, я сначала читаю статьи, затем прошу опытных коллег провести для меня часовой ликбез. А дальше уже тренинги. Например, недавно был крайне полезный двухдневный тренинг Scrum Foundation. А когда я только перешла в QA тест-менеджером, то сразу параллельно с проектом пошла на двухмесячный курс «Школа тест-менеджеров v.2.0». Мне это сильно помогло понять, кто такой тест-менеджер и чем он занят, направить мозги в нужное русло.

Книги читаю мало, так как считаю, что в них много воды и маркетинга. Предпочитаю гуглить и читать предметно. Но всё же я бы рекомендовала новичкам хоть и старую, но актуальную и мотивирующую книгу Романа Савина «Тестирование дот ком». Любопытно было почитать «Как тестируют в Google», хотя ничего особо нового там я не обнаружила. Для быстрого проникновения в философию Scrum рекомендую «Scrum a pocket guide, A smart travel companion».

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

Сейчас у меня в работе два крупных проекта по разработке продуктов для корпоративных клиентов. Один проект по методологии Waterfall для разработки веб-приложения, сервер приложений jBoss, бэкенд на Java. Во втором проекте используется фреймворк Scrum для развития десктопного приложения на C++. Оба приложения активно используют сервисы шины (ESB), MQ-очереди сообщений (продукт IBM). Поэтому очереди сообщений — это первое, с чем мне пришлось разбираться.

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

Мне очень нравится направление CI/CD — автоматическое развёртывание, непрерывная поставка и непрерывная разработка. В этой сфере сейчас создается очень много инструментов и фреймворков. В Scrum-команде мы внедряем авторазвёртывание с использованием Bamboo, поэтому тему CI/CD мне тоже пришлось изучать с нуля, как и принципы Scrum.

Нужно двигаться вперед, планов очень много: на ближайшие два года у меня запланирована учеба на разных курсах, от тестирования мобильных приложений до изучения автоматизации. В первом проекте у нас работает автоматизатор, для создания автотестов он использует Selenium Web-driver + Java, а мануальный тестировщик создает Jerkin-Cucumber-сценарии использования, которые впоследствии будут использоваться в Bamboo, когда в проекте внедрят непрерывную разработку и поставку ПО. Мне нужно в этом разбираться, поэтому по автоматизации планы на тренинги такие:

• Selenium, стартовый курс.
• Python для тестировщиков.
• Selenium WebDriver, полный курс.
• Java для тестировщиков.

Я смогла кардинально поменять профессию после 40 лет. Перейдя в IT, я получила возможность работать с очень интересными технологиями и современными направлениями. Например, наш банк сейчас активно работает со стартапами, и я уже принимала участие в тестировании новинок в биометрии. Важный момент — мне удалось нисколько не потерять в зарплате. И я знаю, что если завтра уеду в Америку или Сингапур, то за месяц-два точно найду работу в QA, благо английский позволяет.

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

Мы продолжаем рассказывать о резидентах Технопарка Университета ИТМО, часть из которых приняла участие в нашем большом интервью. Сегодня поговорим подробнее о восьми компаниях-резидентах Технопарка, успешно развивающих свои проекты, — многие из них получили признание не только в России, но и за рубежом.

В этом материале:

• Софтверные и хардверные разработки резидентов Технопарка ИТМО
• Более эффективные и дешёвые решения в сфере секвенирования генома
• Генотерапевтический анальгетик, работающий до 7 дней
• И другие проекты

Мастерская-лаборатория ФабЛаб — подразделение Технопарка

«Оптимальное движение»

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

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

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

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

---

Датчик стресса

Что это: комплекс мониторинга состояния сердечно-сосудистой системы человека с глубиной прогноза в 2-3 дня. Прибор выполняет функции пульсоксиметра и электрокардиографа и даёт оценку состояния здоровья человека, причём в понятной для неспециалиста форме. Данные, полученные устройством, могут накапливаться и передаваться на ПК/смартфон со специализированным ПО.

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

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

---

VISmart

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

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

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

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

— Дмитрий Павлов, в интервью порталу ITMO.NEWS

После загрузки в программу семантических данных сервис составляете из них граф, визуализирует их и сохраняет полученную диаграмму:


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

---

Adbooking

Что это: рекламная биржа, объединяющая рекламодателей и владельцев рекламных площадей; собственная сеть для демонстрации видеорекламы в общественных местах; система управления контентом.

В чем фишка: проект Adbooking не просто объединяет рекламодателей и площадки — в компании разрабатываются хардверные решения и софт для показа рекламы и управления рекламным контентом. Например, оборудование для создания цифровой видеорекламы:

• Медиаплеер на базе микрокомпьютера и ОС Andriod с системой коммутации видеосигнала, позволяющей использовать плеер для перехвата сигнала с основного канала вещания на сигнал с плеера на время показа рекламы (на основном канале вещания).
• Рекламный тейбл-тент — планшет, вмонтированный в специальный корпус, позволяющий установить его на стол. Тейбл-тент может работать в автономном режиме до 10 часов и может быть оснащен дополнительными кабелями и источником питания, позволяющими заряжать внешние устройства — мобильные телефоны, планшеты.
• Рекламное зеркало — дисплей, смонтированный за зеркалом и помещенный в алюминиевый корпус. Видимая область дисплея внутри зеркала может быть как закрыта зеркальной пленкой для создания эффекта зеркала при выключенном экране (от 50 до 80% отражения), так и быть полностью прозрачной. Может применяться как полностью рекламно-информационное устройство, либо получать сигнал из внешних источников, например, IP-TV или медиа-проигрывателя.
• Информационно-рекламный экран для транспорта — дисплей в вандалозащищенном и травмобезопасном корпусе, которое можно размещать в транспорте и использовать в качестве маршрутного табло или для показа рекламы с удалённым управлением воспроизведением контента.

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

---

FactoryFinder

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

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

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

В будущем: команда проекта продолжает оптимизировать сервис и выходить на новые товарные и географические рынки (в Европу и США).

---

Orbi Prime

Что это: Камера для съемки видео 360 градусов в формфакторе очков, а также технология монтажа видео, снятого на такой гаджет.

В чем фишка:

в отличие от других гаджетов для съемки Orbi Prime позволяет не использовать никаких дополнительных креплений (достаточно просто надеть очки и можно начать снимать) и вести съемку от первого лица.

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

— Александр Морено, технический директор проекта, в интервью порталу ITMO.NEWS

При этом очки позволяют снимать видео в формате до 4k и длительностью до 90 минут. Угол обзора полученной при монтаже сферы составляет 360x300°, гаджет синхронизируется с мобильными устройствами по WiFi и обладает классом защиты IP64. Кстати, функция, собственно, солнцезащитных очков в нем тоже предусмотрена.

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

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

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

---

АТГ Сервис Ген

Что это: компания, выполняющая на заказ молекулярно-биологические эксперименты (синтез олигонуклеотидов, секвенирование ДНК, синтез генов, синтез пептидов, экспрессию белков и другие). Работает с биологическими и фармацевтическими компаниями, государственными научными организациями России и СНГ.

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

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

В организме человека есть белки, которые ответственны за блокирование боли, например, некоторые виды эндорфинов. Когда организм ослаблен, он не может выработать этот белок в достаточном количестве. Если же ввести в организм ДНК, которая кодирует эндорфин, то его выработка увеличится, и человек перестанет чувствовать боль. Таким образом, мы не вводим в организм химическое вещество, тем более, из морфинного или опиоидного ряда.

— Илья Духовлинов, создатель компании «АТГ Сервис Ген» [источник]

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

В будущем: компания планирует запатентовать разработки на международном уровне. На сегодняшний день получены патенты в России, США, Японии и Бразилии.

---

Parseq Lab

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

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

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

В данном случае у ребёнка берётся образец крови, на основе которого проводится секвенирование генома (расшифровка последовательности молекулы ДНК в рамках того гена, который определяет формирование заболевания). Анализ позволяет определить клинически значимые мутации: можно выявить порядка 500 различных вариантов отклонения от нормы.

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

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

— У нас дыра в безопасности.
— Ну, хоть что-то у нас в безопасности.

— Айфоны, вон, каждый год ломают, и ничего.

Я нашел эту ошибку случайно. Уверен, что ни один тестировщик и не подумал бы пойти таким путем — это настолько не очевидно, дико и непредсказуемо, что только случайность помогла мне поучаствовать в bug bounty от Xiaomi. В этом посте расскажу о том, как мне это удалось, что за это было и почему китайские сервисы — зло.

Предыстория

В операционке MIUI можно создать два «пространства» (для простоты я буду называть их профилями) — полностью независимых набора настроек, приложений и файлов, недоступных друг из друга (не считая отдельного приложения «Импорт»). Оба профиля можно запаролить и, допустим, пользоваться устройством с кем-то еще.

В чем, собственно, замес?

Замес в том, что я нашел способ переходить из второго профиля в первый без ввода пароля. Это было возможно через приложение Google Диска, которое по умолчанию установлено в глобальной прошивке на MIUI 8 и сразу доступно во втором профиле.

Второй профиль имеет меньше прав, чем первый — в нем, например, нельзя включать-отключать мобильный интернет или управлять резервными копиями в Google Диске. Если попытаться это сделать, приложение предлагает сходить в системный диалог «Manage Users» и выбрать пользователя, от имени которого совершается действие.

Но что-то пошло не так, и выбор главного профиля в этом окне приводил не к управлению резервными копиями, а к переходу в него без ввода пароля.

Сомнительная аналитика #1

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

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

Как с этим жить?

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

Недолгие поиски привели меня в Xiaomi Security Center. Это сейчас туда худо-бедно процентов на 30 добавили английский перевод, а тогда он выглядел примерно так:


Xiaomi Security Center, sec.xiaomi.com

С гугл-переводчиком я почитал какие-то общие вещи про программу и понял, что найденная уязвимость тянет на категорию High — к ней относят SQL-инъекции, уязвимости в бизнес-логике, XSS с доступом к cookie, получение информации о пользователях устройства, эскалацию привилегий, обход экранов логина и еще несколько вещей. «Окей», подумал я, методом тыка нашел форму и пошел описывать проблему.


Форма отправки уязвимости

Встроенный в хром гугл-переводчик хорош ровно до момента, когда дело доходит до динамически формируемых выпадающих списков. Если поля title, description, proof-of-concept и solution были еще как-то понятны, то, что от меня хотели в списках, я не понимал совсем. Пришлось выковыривать иероглифы из нужных мест страницы через просмотр HTML-кода и переводить вручную.


Спасибо, теперь все понятно

Оказалось, что первый список определял тип уязвимости, второй конкретизировал ее, а в третьем нужно было выбрать масштаб проблемы — от low до major.

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

Сколько пришлось ждать?

11 апреля прямо в Security Center я получил сообщение от безымянного сотрудника Xiaomi.
Оно было таким:
> Thanks for your submission,this is not miui's issue so this got minor and no reward.Thanks for your support.
> Спасибо за отправку, это не проблема miui, она помечена незначительной и останется без награды. Спасибо за поддержку.

«Да как же так? Но это! Же! Дыра! Размером! С! Кимберлитовую! Трубку! В Якутии!» — примерно так я негодовал следующие четыре часа, а потом успокоился и написал ответное сообщение. Вот такое:

> Miui allows to view «manage users» screen and switch account without pass. anyway, do you have plan to fix this issue?
> В MIUI можно попасть на экран «Управление пользователями» и переключаться между аккаунтами без пароля. В любом случае, вы планируете устранять проблему?

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

> sorry,my mistake ,I will test again
> Простите, виноват. Проверю еще раз.

Сомнительная аналитика #2

Из-за «ошибки» оператора дыра могла быть закрыта примерно через бесконечность. Не знаю, как это работает в других программах поиска уязвимостей, но такой подход в Xiaomi явно настраивает на удручающие мысли.

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



К счастью, тестирование не заняло много времени и на следующий день я получил вознаграждение в 1000 (тысячу) монет в магазине внутри Security Center.

Что еще за магазин?

На sec.xiaomi.com есть каталог вещей, которые можно купить за внутреннюю-безопасностную-валюту-победы (извините, я просто не придумал объяснения проще).


Ни в чем себе не отказывайте на тысячу призовых монет

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

Конечно же, я набил корзину юанями за 900 монет (квантизация по 150).
Конечно же, нажал на китайскую версию надписи «Оформить заказ».
И, конечно же, сразу столкнулся с кучей проблем.

Здесь был бы скриншот формы, если бы я его не потерял

Они требовали от меня имя, номер банковской карты и CVV номер ID.


Китайская форма ввода имени

Ни имя, ни номер российского паспорта не подходили — китайский номер ID содержит от 12 до 16 символов, а для имени отводилось всего от 2 до 6.
Но после пройденного награду упускать не хотелось, и я решил написать письмо в техподдержку и узнать, как выводят деньги иностранцы (которых, судя по никам ловцов уязвимостей, было много). Окей, с переводчиком ищем нужный раздел, заходим…


… черт.

Ладно, пришлось выбирать товары. В тысячу монет вместились умная лампа, умная 360-градусная камера и bluetooth-колонка. Вместе они стоят около 7200 рублей (или 124 доллара).

Оставшиеся три десятка монет я проиграл в «колесе удачи» там же на сайте.

Благо с оформлением проще, и пришлось просто придумать, как вместить адрес международной доставки в поле с ограничением в 100 символов, а также сократить имя до шести букв — Evgeny, а полное написать в «Notes».

Заканчивался июль.

А долго мне еще ждать?

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

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

Доставка заняла еще неделю, и я наконец-то получил посылку с наградой за баг баунти в Xiaomi. Приятно, что курьер из EMS доставил ее до двери и не пришлось никуда ехать. Happy end.

В комментариях готов ответить на ваши вопросы о любых этапах этого растянутого во времени процесса.
Спасибо за внимание!

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

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

Как и всегда для осуществления данной атаки есть пару ограничений:

1. Мы должны быть подключены к атакуемой точке доступа.
2. У нас должна быть возможность прослушивать широковещательный трафик в сети.

И так как же это работает? Атака разделяется на несколько этапов:

1. Производим атаку DHCP Starvation;
2. Отправляем WiFi DeAuth пакеты;
3. Перехватываем ARP запросы от клиентов, отвечаем на них, чтобы создать конфликт IP-адресов и принудить клиента отправить DHCPDECLINE;
4. Перехватываем DHCPDISCOVER и DHCPREQUEST запросы, отвечаем на них;
5. Profit!

Разберемся в этой схеме поподробнее.

DHCP Starvation

Подключаемся к атакуемой WiFi сети и производим атаку DHCP Starvation с целью переполнить пул свободных IP-адресов.
Как это работает:

1. Формируем и отправляем широковещательный DHCPDISCOVER-запрос, при этом представляемся как DHCP relay agent. В поле giaddr (Relay agent IP) указываем свой IP-адрес 192.168.1.172, в поле chaddr (Client MAC address) — рандомный MAC 00:01:96:E5:26:FC, при этом на канальном уровне в SRC MAC выставляем свой MAC-адрес: 84:16:F9:1B:CF:F0.
   

   
   

2. Сервер отвечает сообщением DHCPOFFER агенту ретрансляции (нам), и предлагает клиенту с MAC-адресом 00:01:96:E5:26:FC IP-адрес 192.168.1.156
   

   
   

3. После получения DHCPOFFER, отправляем широковещательный DHCPREQUEST-запрос, при этом в DHCP-опции с кодом 50 (Requested IP address) выставляем предложений клиенту IP-адрес 192.168.1.156, в опции с кодом 12 (Host Name Option) — рандомную строку dBDXnOnJ. Важно: значения полей xid (Transaction ID) и chaddr (Client MAC address) в DHCPREQUEST и DHCPDISCOVER должны быть одинаковыми, иначе сервер отбросит запрос, ведь это будет выглядеть, как другая транзакция от того же клиента, либо другой клиент с той же транзакцией.
   

   
   
4. Сервер отправляет агенту ретрансляции сообщение DHCPACK. С этого момента IP-адрес 192.168.1.156 считается зарезервированным за клиентом с MAC-адресом 00:01:96:E5:26:FC на 12 часов (время аренды по умолчанию).
   
   

WiFi DeAuth

Следующим шагом производим Wi-Fi Deauth. Работает эта схема примерно так:

Переводим свободный беспроводной интерфейс в режим мониторинга:

Отправляем deauth пакеты с целью отсоединить атакуемого клиента 84:16:F9:19:AD:14 WiFi сети ESSID: WiFi DHCP MiTM:

DHCPDECLINE

После того как клиент 84:16:F9:19:AD:14 отсоединился от точки доступа, вероятнее всего, он заново попробует подключиться к WiFi сети WiFi DHCP MiTM и получить IP-адрес по DHCP. Так как ранее он уже подключались этой сети, то будет отравлять только широковещательный DHCPREQUEST.

Мы перехватываем запрос клиента, но ответить быстрее точки доступа мы, само собой, не успеем. Поэтому клиент получает IP-адрес от DHCP-сервера, полученный ранее: 192.168.1.102. Далее клиент с помощью протокола ARP пытается обнаружить конфликт IP-адресов в сети:

Естественно, такой запрос широковещательный, поэтому мы можем перехватить и ответить на него:

После чего клиент фиксирует конфликт IP-адресов и отправляет широковещательное сообщение отказа DHCP — DHCPDECLINE:

DHCPDISCOVER

И так, последний этап атаки. После отправки DHCPDECLINE клиент с самого начала проходит процедуру получения IP-адреса, а именно отправляет широковещательный DHCPDISCOVER. Легитимный DHCP-сервер не может ответить на этот запрос, так как пул свободных IP-адресов переполнен после проведения атаки DHCP starvation и поэтому заметно тормозит, зато на DHCPDISCOVER можем ответить мы — 192.168.1.172.

Клиент 84:16:F9:19:AD:14 (Win10-desktop) отправляет широковещательный DHCPDISCOVER:

Отвечаем DHCPOFFER:

В DHCPOFFER мы предложили клиенту IP-адрес 192.168.1.2. Клиент получив данное предложение только от нас отправляет DHCPREQUEST, выставляя при этом в requested ip значение 192.168.1.2.

Клиент 84:16:F9:19:AD:14 (Win10-desktop) отправляет широковещательный DHCPREQUEST:

Отвечаем DHCPACK:

Клиент принимает наш DHCPACK и в качестве шлюза по умолчанию и DNS-сервера выставляет наш IP-адрес: 192.168.1.172, а DHCPNAK от точки доступа присланный на 2 секунды позже просто проигнорирует.

Вопрос: Почему точка доступа прислала DHCPOFFER и DHCPNAK на 2-е секунды позже, да еще и предложила тот же IP-адрес 192.168.1.102, ведь клиент отказался от него?

Чтобы ответить на данный вопрос немного изменим фильтр в WireShark и посмотрим ARP запросы от точки доступа:

Ответ: После проведения атаки DHCP Starvation у DHCP-сервера не оказалось свободных IP-адресов, кроме того, от которого отказался один из клиентов: 192.168.1.102. Поэтому, получив DHCPDISCOVER-запрос, DHCP-сервер в течении 2-ух секунд отправляет три ARP-запроса, чтобы узнать кто использует IP-адрес: 192.168.1.102, и после того, как сервер убедился что данный IP-адрес свободен, поскольку никто не ответил, выдает его клиенту. Но уже слишком поздно злоумышленник успел ответить быстрее.

Результаты:

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

Видео проведения атаки на MacOS Siera и Windows 10:

Ну и конечно же PoC.

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

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

Другие выпуски дайджеста:

• Технологии DPI и оборудование СОРМ
• DPI-дайджест: IPv6, SD-WAN и многое другое
• Дайджест материалов по теме Deep Packet Inspection
• Анализ трафика, сравнение платформ и производителей DPI-систем

/ Flickr / Pascal / PD

5 проблем NFV

• Знакомство с основными сложностями в работе с Network Functions Virtualization и виртуальными сетевыми узлами. Смотрим на архитектуру, работу с устаревшими сетями, проблемы с безопасностью и ситуацию со стандартами и практическими кейсами.

VPLS для доступа к ЦОД

• Virtual Private LAN Service — это один из наиболее гибких инструментов для получения доступа к серверам, расположенным в дата-центрах. Здесь мы приводим небольшой туториал по способам подключения, рассказываем про особенности VPLS и преимущества виртуализации.

Сетевые платы Bypass – отказоустойчивость в сетях с DPI

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

Конвергенция и унификация – несколько задач на одном устройстве

• Говорим о преимуществах конвергентной инфраструктуры, приводим примеры популярных конвергентных систем и проводим параллели с системой контроля и анализа трафика СКАТ DPI.

ИБ

Этапы проведения кибератак

• Рассказываем про «исследование» жертвы, установление контроля, организацию доступа и другие этапы атак. Помимо этого кратко останавливаемся на мерах безопасности.

Что нужно, чтобы стать инженером по ИТ-безопасности

• Разбираемся с тем, что входит в компетенции инженера по ИТ-безопасности. И кратко останавливаемся на том, что нужно для начала карьерного пути в этой сфере деятельности.

VPN – типы подключения и проверка безопасности

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

Шифрованный трафик может быть классифицирован

• О том, как провайдер может гибко управлять трафиком без необходимости дешифрования пользовательских данных. Говорим о SSL/TLS-, P2P- и Skype-трафике.

Как безопасно обмениваться паролями в вашей сети

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

/ Flickr / Pascal / PD

Закон и порядок

Фильтрация URL в рамках закона

• Говорим о базовых способах блокировки: по IP-адресу, по SNI и по сертификату. Разбираем пример соответствующей MITM-атаки и подчеркиваем противозаконность подобных действий.

Оповещение населения о ЧС – новая обязанность интернет-провайдера

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

Типовой план внедрения СОРМ-3

• Что входит в перечень требований для внедрения системы СОРМ-3 — смотрим на эту задачу с точки зрения заказчика и исполнителя.

Что будет с интернет-провайдерами после 1 июля 2018 года

• Рассматриваем «пакет Яровой», базовые требования и штрафы. Помимо этого мы говорим о том, как можно смягчить негативные последствия от данного нововведения.

Разное

Вебинар «СОРМ-3 и фильтрация трафика»

• Сегодня (28.09.2017) в 11-00 по МСК компания VAS Experts проведет вебинар «СОРМ-3 и фильтрация трафика». Мы расскажем о практических кейсах, сценариях, особенностях, отличиях и различных нюансах внедрения СОРМ–1, СОРМ–2, СОРМ–3.

VAS Experts на ASIA 2017 GCCM в Сингапуре

• Рассказываем о нашем участии в 7-й ежегодной встрече членов клуба ASIA 2017 GCCM. На GCCM наша компания представляла продукт СКАТ DPI.

Интервью с Максимом Хижинским – C++ разработчиком системы DPI

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

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

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

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

В роли Сатоши Накамото выступила Вика из отдела контента — она заполнила наш стандартный бриф как заказчик. Я стал менеджером проекта и выбрал дизайнеров для работы над логотипом и стилем.

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

Обозначив задачу, мы начали погружаться в тему:


Собираем абстрактные референсы с частицами, волнами и прочими метафорами

Превращаем первые мысли в графику:


Марина перебирает варианты


Первые варианты напоминают монетку

Попробовали накидать футуристичный стиль:


Изображаем монету, излучающую свет


Пробуем более «дерзкое» и непривычное сочетание цветов

Обыгрываем тему космоса как чего-то бескрайнего и неизведанного:


Цвета по-прежнему необычные, но не такие яркие


Прорабатываем тему излучения и частиц

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


Делаем цельную круглую «монету»


Пробуем сделать волны-туманности


Играем с формой, плотностью и цветом, ушли в тему облаков


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


Стараемся не отходить от идеи «современного золота»

Приходим к финальному варианту, объединившему в себе идеи «динамической, абстрактной сущности» и «современного золота». Он похож и на круги на воде, и на туманности и, конечно, анимирован:


Финальный логотип Биткоин

Мы сразу знали, что будем делать динамику, поэтому сразу готовили все частицы к анимации:


Дизайнер Саша работает над анимацией логотипа

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


Модель банкомата Bitcoin в 3D Max


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


Визуализация банкомата днем и ночью

Итог:

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

Сейчас мы готовим следующий концепт, чтобы его не пропустить — подписывайтесь на Логомашину ВКонтакте!

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

В 2015 году к ЕРАМ присоединилась геймдев-студия Signus Labs. Внутри ЕРАМ она стала подразделением Virtual Reality, Augmented Reality and Game Experience Delivery. Там разрабатывают игровые решения для бизнеса.

Зачем корпорациям клиенты-игроки, что за игры делают в ЕРАМ и как устроена работа геймдизайнеров и VR/AR-разработчиков?


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

Павел, менеджер подразделения:

Для ЕРАМ смысл игровых технологий не в том, чтобы разрабатывать игры как таковые. Мы делаем много решений на игровом инструментарии: Unity-программисты делают 3D, дополненную и виртуальную реальность, но это игры для бизнеса.

В XXI веке мы пришли в постиндустриальное общество, где люди больше не покупают товары, услуги или функции. Теперь они покупают истории, образы, впечатления и игру. Этот новый для традиционной индустрии опыт работы с аудиторией, а мы в геймдеве хорошо научились этому за последние 30 лет. Мы берем готовые технологии и механики геймдева, — 3D-визуализацию, AR, VR, геймификацию — и перекладываем на традиционный бизнес. Вот зачем мы здесь.

Всё начинается с геймдизайна

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

Мария, геймдизайнер:

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

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

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

Владимир, геймдизайнер:

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

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

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



Мы разработали приложение для шлема виртуальной реальности HTC Vive для одного из наших заказчиков. Оно обучает новых сотрудников пользоваться оборудованием на нефтяных вышках. Казалось бы, обучающее приложение, но в нем мы решали чисто игровые задачи. Например, в реальном мире приборы находятся далеко друг от друга. Нам нужно было сделать так, чтобы пользователь не блуждал по виртуальной реальности в поисках незнакомых машин и быстро знакомился с оборудованием. Это классический случай левел-дизайна: каждый новый прибор и новая точка на карте – это переход на следующий уровень. Еще одна задача – увлечь пользователя: мотивированный человек справится с обучением быстрее, чем человек скучающий. Поэтому бизнесу выгодно делать обучение интересным, и это уже история про геймификацию. Даже простой индикатор выполнения добавляет азарта и мотивирует на достижение результата. Когда пользователь видит на экране «0/19», он понимает, что ему нужно пройти 19 точек, и воспринимает это как игровую миссию. Геймификация идет на пользу всем: сотруднику нравится учиться, а бизнес быстрее получает сотрудника, готового к работе.

VR – это постоянные эксперименты и поиск правильной метафоры

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

Георгий, VR-разработчик:

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

Богатое поле для экспериментов – пользовательский интерфейс. Для виртуальной реальности UI в привычном понимании как будто бы не нужен. Ты должен видеть мир вокруг себя, а стандартный интерфейс разрушает цельную картину. Какой смысл читать текст в 3D? Куда лучше будет перенести UI в подходящую 3D-форму. Условно, вместо того чтобы рисовать индикатор здоровья стандартным сердечком в правом верхнем углу экрана, в VR можно перенести его на солнце. Чем меньше остается здоровья, тем больше солнечный круг заполняется черным, и наоборот. Вот это уже подходящий интерфейс для VR.

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

Полезное решение – это интересное решение

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

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

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

Проработав некоторые детали, в основном относящиеся к зубодробительным событиям PowerShell, я смог заявить о своей победе и зарегистрировал патент на платформу безопасности на базе скриптов — SSP (Security Scripting Platform ).

Соединенные штаты PowerShell

Пока я получал незабываемый опыт работы с PowerShell, я понял, что некоторые из вас могут не вспомнить мои результаты работы со скриптами.
Давайте вспомним их вместе.

В первой заметке я представил удивительную строку кода PowerShell, которая следит за событиями доступа к файлам и запускает блок скрипта, аналогичный PS, — то есть код скрипта, который выполняется в собственной области памяти.

1.	Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance ISA 'CIM_DataFile' and TargetInstance.Path = '\\Users\\bob\' and targetInstance.Drive = 'C:' and (targetInstance.Extension = 'doc' or targetInstance.Extension = 'txt)' and targetInstance.LastAccessed > '$($cur)' " -sourceIdentifier "Accessor" -Action $action

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

Это упрощенная версия технологии анализа поведения пользователей, которая широко применяется нами здесь в компании Varonis.

Пока все идет хорошо.

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

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

Почему?

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

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

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

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

Сообщения и события

После того, как я провел несколько долгих дней за изучением форумов разработчиков, я наконец наткнулся на функцию PowerShell под именем Register-EngineEvent.

Что представляет собой этот командлет PowerShell?

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

Дело в том, что у register-EngineEvent есть два варианта работы. С параметром -forward этот командлет работает как издатель событий. Без параметра -forward он выполняет роль получателя.

Понятно?

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

В первом из этих двух скриптов, отрывок из которого представлен далее, я показываю, как я регистрировал публичное имя события Delta с помощью строки -Register-EngineEvent -forward, а затем ожидал внутренних событий доступа к файлам. Когда такое событие происходило, я отправлял сообщение о внутреннем событии файла — говоря на языке PowerShell, пересылал его — соответствующему командлету Register-EngineEvent в скрипте-классификаторе во втором отрывке кода.

1.	Register-EngineEvent -SourceIdentifier Delta -Forward
2.	While ($true) {
3.	$args=Wait-Event -SourceIdentifier Access # wait on internal file event
4.	Remove-Event -SourceIdentifier Access
5.	if ($args.MessageData -eq "Access") { 
6.	#do some plain access processing 
7.	New-Event -SourceIdentifier Delta -EventArguments $args.SourceArgs -MessageData $args.MessageData #send event to classifier via forwarding
8.	}
9.	elseif ($args.MessageData -eq "Burst") {
10.	#do some burst processing
11.	New-Event -SourceIdentifier Delta -EventArguments $args.SourceArgs -MessageData $args.MessageData #send event to classifier via forwarding
12.	}
13.	}

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

1.	Register-EngineEvent -SourceIdentifier Delta -Action {
2.	
3.	Remove-Event -SourceIdentifier Delta
4.	if($event.MessageData -eq "Access") {
5.	$filename = $args[0] #got file!
6.	Lock-Object $deltafile.SyncRoot{ $deltafile[$filename]=1} #lock&load 
7.	}
8.	elseif ($event.Messagedata -eq "Burst") {
9.	#do something 
10.	}
11.	
12.	}

Запутались? А я говорил недавно, что обработка событий файлов — это непросто, и что мои учебные скрипты не справятся с обработкой реальных производственных нагрузок?
Путаница возникает, поскольку командлеты New-Event и Wait-Event для внутреннего обмена сообщениями о событиях отличаются от функций внешнего обмена сообщениями о событиях, предоставленных в Register-EngineEvent.

Еще больше путаницы

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

1.	Import-Module -Name .\pslock.psm1 -Verbose
2.	function updatecnts {
3.	Param ( 
4.	[parameter(position=1)] 
5.	$match, 
6.	[parameter(position=2)]
7.	$obj
8.	)
9.	
10.	for($j=0; $j -lt $match.Count;$j=$j+2) { 
11.	switch -wildcard ($match[$j]) {
12.	'Top*' { $obj| Add-Member -Force -type NoteProperty -Name Secret -Value $match[$j+1] }
13.	'Sens*' { $obj| Add-Member -Force -type NoteProperty -Name Sensitive -Value $match[$j+1] }
14.	'Numb*' { $obj| Add-Member -Force -type NoteProperty -Name Numbers -Value $match[$j+1] } 
15.	}
16.	
17.	}
18.	
19.	return $obj
20.	}
21.	
22.	$scan = {
23.	$name=$args[0]
24.	function scan {
25.	Param (
26.	[parameter(position=1)]
27.	[string] $Name
28.	)
29.	$classify =@{"Top Secret"=[regex]'[tT]op [sS]ecret'; "Sensitive"=[regex]'([Cc]onfidential)|([sS]nowflake)'; "Numbers"=[regex]'[0-9]{3}-[0-9]{2}-[0-9]{3}' }
30.	
31.	$data = Get-Content $Name
32.	
33.	$cnts= @()
34.	
35.	if($data.Length -eq 0) { return $cnts} 
36.	
37.	foreach ($key in $classify.Keys) {
38.	
39.	$m=$classify[$key].matches($data) 
40.	
41.	if($m.Count -gt 0) {
42.	$cnts+= @($key,$m.Count) 
43.	}
44.	} 
45.	$cnts 
46.	}
47.	scan $name
48.	}
49.	
50.	
51.	$outarray = @() #where I keep classification stats
52.	$deltafile = [hashtable]::Synchronized(@{}) #hold file events for master loop 
53.	
54.	$list=Get-WmiObject -Query "SELECT * From CIM_DataFile where Path = '\\Users\\bob\' and Drive = 'C:' and (Extension = 'txt' or Extension = 'doc' or Extension = 'rtf')" 
55.	
56.	
57.	#long list --let's multithread
58.	
59.	#runspace
60.	$RunspacePool = [RunspaceFactory]::CreateRunspacePool(1,5)
61.	$RunspacePool.Open()
62.	$Tasks = @()
63.	
64.	
65.	foreach ($item in $list) {
66.	
67.	$Task = [powershell]::Create().AddScript($scan).AddArgument($item.Name)
68.	$Task.RunspacePool = $RunspacePool
69.	
70.	$status= $Task.BeginInvoke()
71.	$Tasks += @($status,$Task,$item.Name)
72.	}
73.	
74.	
75.	Register-EngineEvent -SourceIdentifier Delta -Action {
76.	
77.	Remove-Event -SourceIdentifier Delta
78.	if($event.MessageData -eq "Access") {
79.	$filename = $args[0] #got file
80.	Lock-Object $deltafile.SyncRoot{ $deltafile[$filename]=1} #lock& load
81.	}
82.	elseif ($event.Messagedata -eq "Burst") {
83.	#do something
84.	}
85.	}
86.	
87.	while ($Tasks.isCompleted -contains $false){
88.	
89.	}
90.	
91.	#check results of tasks
92.	for ($i=0; $i -lt $Tasks.Count; $i=$i+3){
93.	$match=$Tasks[$i+1].EndInvoke($Tasks[$i])
94.	
95.	
96.	if ($match.Count -gt 0) { # update clasafication array 
97.	$obj = New-Object System.Object
98.	$obj | Add-Member -type NoteProperty -Name File -Value $Tasks[$i+2]
99.	#defaults
100.	$obj| Add-Member -type NoteProperty -Name Secret -Value 0
101.	$obj| Add-Member -type NoteProperty -Name Sensitive -Value 0
102.	$obj| Add-Member -type NoteProperty -Name Numbers -Value 0
103.	
104.	$obj=updatecnts $match $obj
105.	$outarray += $obj
106.	} 
107.	$Tasks[$i+1].Dispose()
108.	
109.	}
110.	
111.	$outarray | Out-GridView -Title "Content Classification" #display
112.	
113.	#run event handler as a separate job
114.	Start-Job -Name EventHandler -ScriptBlock({C:\Users\bob\Documents\evhandler.ps1}) #run event handler in background
115.	
116.	
117.	while ($true) { #the master executive loop
118.	
119.	
120.	Start-Sleep -seconds 10
121.	Lock-Object $deltafile.SyncRoot { #lock and iterate through synchronized list
122.	foreach ($key in $deltafile.Keys) { 
123.	
124.	$filename=$key
125.	
126.	if($deltafile[$key] -eq 0) { continue} #nothing new
127.	
128.	$deltafile[$key]=0
129.	$match = & $scan $filename #run scriptblock
130.	#incremental part
131.	
132.	$found=$false
133.	$class=$false
134.	if($match.Count -gt 0) 
135.	{$class =$true} #found sensitive data
136.	if($outarray.File -contains $filename) 
137.	{$found = $true} #already in the array 
138.	if (!$found -and !$class){continue}
139.	
140.	#let's add/update
141.	if (!$found) {
142.	
143.	$obj = New-Object System.Object
144.	$obj | Add-Member -type NoteProperty -Name File -Value $Tasks[$i+2]
145.	#defaults
146.	$obj| Add-Member -type NoteProperty -Name Secret -Value 0
147.	$obj| Add-Member -type NoteProperty -Name Sensitive -Value 0
148.	$obj| Add-Member -type NoteProperty -Name Numbers -Value 0
149.	
150.	$obj=updatecnts $match $obj
151.	
152.	}
153.	else {
154.	$outarray|? {$_.File -eq $filename} | % { updatecnts $match $_} 
155.	}
156.	$outarray | Out-GridView -Title "Content Classification ( $(get-date -format M/d/yy:HH:MM) )" 
157.	
158.	} #foreach
159.	
160.	} #lock
161.	}#while
162.	
163.	Write-Host "Done!"

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

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

Это классическая ситуация состязания. И для обработки этой ситуации я решил использовать синхронизированныепеременные PowerShell.

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

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

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

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



В основе статьи — доклад Дугласа Крокфорда (Douglas Crockford) с июньской конференции HolyJS 2017 в Санкт-Петербурге (презентацию доклада можно найти тут)

Пальцы

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

Инструменты

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

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

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

Счет

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

Письменность

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

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

Давайте рассмотрим подробнее некоторые исторические системы счисления.

Египет

Так выглядели числа в Египте.


У египтян была десятичная система. Для каждой степени 10 у них был предусмотрен свой иероглиф. Палка представляла единицу, кусок верёвки — 100, палец — 10000, а парень с поднятыми руками — миллион (это демонстрирует некоторую математическую изощренность, т.к. у них был символ, обозначающий не абстрактное понятие «много», а точно «миллион» — ни больше, ни меньше).

Египтяне придумали много других вещей: треугольник 3 на 4 на 5 с прямым углом (они знали, зачем этот угол нужен), действительно умную систему для работы с дробями. У них было приближение для числа Пи и много чего еще.

Финикия

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

Греция

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

Греки использовали тот же набор символов для записи чисел. Они взяли первые 9 букв алфавита для обозначения цифр с 1 по 9, следующие 9 букв — для десятков от 10 до 90, и еще 9 букв для сотен — от 100 до 900. Свою систему они передали римлянам.

Рим

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

Одна из проблем египетской системы заключалась в том, что для записи числа 99 требовалась последовательность из 18 символов. Римляне хотели сократить запись. Для этого они придумали символы, представляющие половину десяти или половину сотни (тысячи). Один у них был представлен символом I (или палкой), 10 — X (пучок палок, соединенных вместе), а 5 — V, что есть всего лишь X пополам.

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

Китай

Между тем в Китае творились действительно интересные вещи.


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

Индия

Больший скачок произошел в Индии.



Математики в Индии пришли к идее нуля — числа, которое ничего не представляло. И они догадались использовать его на позиционной основе. Для отображения чисел применялись всего 10 символов, но они могли быть объединены для создания любого числа. Это было действительно важной идеей.

Тиражирование идеи

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

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

Запись чисел и математика

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


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

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

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

Важная идея заключается в том, что индийские числа научили нас математике.



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

Целые числа

Данная система также допускала отрицательные числа.


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

Вещественные числа

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


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

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


Но с годами разделительный символ менялся.

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


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

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

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

Основание

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

Как это произошло? Они просто посчитали пальцы на обеих руках. И это сработало.

Но есть и другие культуры, которые записывали числа по-другому. Например, в Америке была система счисления с основанием 20. Знаете, как они до нее додумались? Полагаю, это очевидно: они посчитали пальцы не только на руках, но и на ногах. И это тоже сработало. У них была развитая цивилизация. Они выполняли достаточно много вычислений, но использовали основание 20.

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

Компромиссы: 60

Шумеры использовали основание 60. Да и мы все еще придерживаемся основания 60, верно? Мы так считаем наше время и делаем географические измерения. Географическим приложениям приходится использовать систему координат на базе системы счисления с основанием 60. Это добавляет ненужную сложность.

Как появилось основание 60? Я думаю, когда города росли, они поглощали много мелких поселений, объединяя их в большие. В какой-то момент они попытались объединить сообщество, которое использовало основание 10, с сообществом, которое взяло в качестве основания 12. Наверняка был какой-то король или комитет — кто-то должен был решить, как объединить их. Правильный вариант был — использовать основание 10. Второй вариант — развиваться с основанием 12. Но вместо этого они выбрали худший вариант из возможных — использовали основание, являющееся наименьшим общим кратным. Причина, по которой было принято такое решение, состоит в том, что комитет не мог решить, какой из вариантов лучше. Они пришли к компромиссу, который, по их мнению, похож на то, что все хотели. Но дело же не в том, кто и что хочет.

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

Двоичная система

Действительно интересная вещь, связанная с основанием, — появление двоичной системы. Мы можем взять индийскую систему и просто заменить 10 на 2.


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

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

• Знаковая величина (Signed magnitude representation). В этом случае мы просто добавляем дополнительный двоичный бит к числу и решаем, в каком из состояний этот бит соответствует положительному числу, а в каком — отрицательному. И неважно, поставим ли мы этот бит спереди или сзади (это всего лишь вопрос конвенции). Недостатком этого способа является присутствие двух нулей: положительного и отрицательного, что не имеет смысла, поскольку ноль не имеет знака.
  
• Первое дополнение (One’s complement), в котором мы выполняем операцию побитового нет для числа, чтобы сделать его отрицательным. Помимо двух нулей (положительного и отрицательного — как в предыдущем варианте) у этого представления присутствует проблема переноса: при обычном сложении двух чисел, представленных таким образом, для получения корректного результата необходимо в конце добавлять 1 бит. Но в остальном это работает.
  
• Второе дополнение (Two's complement), в котором удалось обойти проблему переноса. Отрицательное N представляется не побитовым отрицанием положительного N, а им же + 1. Помимо отсутствия проблемы переноса мы получаем только один нуль, что очень хорошо. Но при этом мы получаем дополнительное отрицательное число. И это проблема, потому что вы не можете получить абсолютное значение этого числа — вместо этого вы получите то же отрицательное число. Это потенциальный источник ошибок.
  

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


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

Types

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

int

У нас есть много языков, где под разными именами есть int32. Если мы сложим два числа int32, к какому типу будет относиться результат? Ответ — int33, потому что в результате сложения вы можете получить число, которое немного больше int32.

Здесь Java ошибается. Java говорит, что это int32.

Еще один пример — умножение int32 на int32. Что мы получим в результате? Похоже, int63.


Когда в результате обычного вычисления получается результат, который выходит за рамки типа, мы получаем переполнение. И наши CPU знают об этом. Например, в архитектуре Intel в ЦП есть флаг переноса, который содержит этот 33-й бит. Также на архитектуре Intel, если вы делаете умножение 32-битных чисел, вы получаете 64-битный результат. Т.е. предусмотрен регистр, который содержит необходимые вам «дополнительные» 32 бита. И есть флаг переполнения, который устанавливается, если требуется игнорировать высокий порядок умножения. Он сообщает, что произошла ошибка. К сожалению, Java не позволяет вам получать эту информацию. Она просто отбрасывает все, что является проблемой.

Что вообще должно происходить, при переполнении? Здесь есть несколько вариантов действий:

• мы можем хранить значение null, что, я думаю, очень разумно;
  
• или максимально возможную часть (насыщение — saturation). Это может быть разумно при обработке сигналов и в компьютерной графике. Однако вы не захотите так делать в финансовых приложениях;
  
• можно выдавать ошибку — машина должна вызвать исключение или что-то должно произойти. Софт должен понять, что в вычислениях произошла путаница и нужно исправить ситуацию;
  
• некоторые говорят, что программа должна остановиться. Это довольно резкая реакция, но такой вариант работал бы, если бы машина не просто останавливалась, а как-то сообщала, что что-то не так.
  

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

Разбиение чисел на значения из разных регистров

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

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

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

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

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


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

Вот как выглядит стандарт вычислений с плавающей запятой в двоичной системе:


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

Однако с этой записью есть проблема: в ней 0,1 + 0,2 не равно 0,3.


Результат близок, но он неправильный.

Давайте посмотрим, что происходит.


Представим числовой ряд. 0,1 — это приблизительно 1/16 + 1/32, но немного больше, поэтому нам понадобятся ещё несколько бит. По мере движения по числовому ряду мы получим бесконечно повторяющуюся серию 0011, похожую на то, что происходит с 1/3 в десятичной дроби.


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

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


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

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

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

А поскольку ни одно из наших чисел не представлено точно, все вычисления ошибочны! Это означает, что (A + B) + C не то же самое, что A + (B + C), что порядок, в котором вы выполняете вычисления, может изменить результат.

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

В то время были две школы вычислений:

• те, кто занимались научным трудом, писали на Фортране с использованием чисел с плавающей точкой в двоичной системе;
  
• те, кто занимались бизнесом, писали на Cobol, используя двоично-десятичный код (binary coded decimal, BCD). Двоично-десятичный код выделяет 4 бита для каждой цифры и ведет обычный подсчет в десятичной системе (используя обычную арифметику).
  

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

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

Проблема с типами

В большинстве современных языков программирования присутствует путаница из-за ошибочных типов данных. Например, если вы пишите на Java, каждый раз создавая переменную, свойство или параметр, вам нужно правильно выбрать тип из Bite, Char, Short, Int, Long, Float, Double. И если вы выберете неправильно, программа может не заработать. Причем ошибка проявится не сразу, и в тестах её не будет видно. Она покажет себя в будущем, когда произойдёт переполнение и связанные с этим плохие вещи.

Что может случиться? Одним из самых впечатляющих примеров был отказ Aryan 5. Это ракета, отправленная Европейским космическим агентством. Она сильно отклонилась от курса, а затем взорвалась через несколько секунд после старта. Причиной тому была ошибка в программном обеспечении, написанном на Ада. Здесь я перевел ошибку на Java:



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

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

DEC64

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

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

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

DEC64 может точно представлять десятичные дроби, содержащие до 16 цифр, чего вполне достаточно для большинства наших приложений. Вы можете представлять числа от 1*10^-27 до 3 с 143 нулями.

DEC64 очень похож на исходные числа с плавающей точкой, разработанные в 40-х годах. Число представлено в виде двух чисел, которые упакованы в 64-битное слово. Коэффициент представлен 56 битами, а показатель — 8 битами.


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

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

С форматом DEC64 я не надеюсь попасть в следующий JavaScript, поскольку это фундаментальное изменение. Зная как работает комитет, я не думаю, что это возможно. DEC64 поможет создателю следующего языка программирования (я надеюсь, что JavaScript не станет последним языком программирования — мы не можем оставить его детям; мы должны предложить им что-то другое).

Неопределенности и нули

=Давайте вернемся к числам.

Что такое 0/0?

• Большинство математиков скажут, что это значение не определено, подразумевая, что глупо так делать — такое выражение не имеет смысла (JavaScript определяет это как Undefined). Такая позиция хороша для математики, потому что там все происходит в теоретическом пространстве. Но это не работает для вычислений, потому что если кто-то может подать эти данные на вход машины, та должна как-то отреагировать (вы не можете сказать, что дизайн машины не определён — что-то должно произойти).
  
• Еще одна теория говорит, что машина должна загореться, потому что никто не будет в здравом уме пытаться делить 0 на 0, так что этого никогда не должно произойти. Но мы знаем, что это неправда. Потому что если что-то может произойти, это произойдет.
  
• Другая версия — это должно быть null или какое-то иное понятие, которое говорит, что это не значение. И это разумно.
  
• Еще одна школа считает, что результат должен быть нулевым. Есть математики, которые уверены в этом, но для большинства бизнес-задач такой результат не имеет смысла. Если в прошлом месяце мы продали 0 единиц товара, и общая прибыль по этим единицам составляла 0, какова была средняя прибыль за товар? 0?
  
• Некоторые люди говорят, что это 1, потому что N / N = 1.
  
• Когда-то я работал на мэйнфрейме, где результат был 2. Это была машина, которую создал Сеймур Крей — величайший компьютерный дизайнер в истории. Я ввел 0/0 и получил 2. Могу представить себе диалог в Control Data Corporation. Кто-то сказал: «Сеймур, есть проблема с вашей схемой деления!». «В чем проблема?». «Если кто-то разделит 0 на 0, получит 2!». И Сеймур говорит: «Послушай… Такой операции не должно быть. Ни один разумный человек никогда не должен этого делать. И если я включу дополнительную логику для этого случая, чтобы определить поведение машины, т.е. добавлю ещё одну проверку, она ухудшит производительность для всех, в том числе, для умных людей, которые не выполняют таких операций. И это сделает машину дороже. Я не собираюсь этого делать только из-за того, что какой-то идиот хочет разделить 0 на 0».
  

Также меня интересует, чему равно 0 * n для любого значения n.
Я думаю, что это 0. Но были компиляторы, которые, если встречали в умножении 0, не делали умножение вовсе. Это было большим плюсом к скорости. К сожалению, когда был создан стандарт записи чисел с плавающей точкой, такой подход был объявлен ошибочным, потому что если n является NaN, то результат 0 x NaN не равен нулю.

Почему мы вообще должны заботиться об этом?

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

Современные процессоры имеют очень длинные протоколы декодирования команд, которые занимают много циклов. Но они могут быстро перерабатывать множество инструкций, пока нет никаких условных переходов. Если же есть условный переход, все останавливается, пока не будет ясно, в какую сторону двигаться дальше. И это действительно замедляет работу. Есть способ написания кода, когда вы вместо выбора между двумя значениями (условия), выполняется дополнительное действие — умножение на 0 или 1, являющиеся результатом логической операции (того самого условия). Хотя это дополнительная работа, ее исполнение может быть быстрее, чем выполнение кода с условными переходами. Поэтому я рекомендую все операции с 0 (деление, умножение, деление с остатком) приравнивать к нулю.

Как и DEC64, эта идея предложена для следующего поколения прикладных языков программирования.

Вместо заключения

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


Я хочу начать с Леонардо Фибоначчи из Пизы. В конце XII века Леонардо посетил Аравию и узнал удивительные вещи, которые арабские математики воплотили через свою систему счисления — алгебру, геометрию, алгоритмы. Он привез их в Европу и написал книгу, которую опубликовал в 1202 году. В течение следующего столетия эта книга преобразовала Европу. Он создал базу для новых форм банковского дела, что привело к увеличению капитала, подпитывающего Ренессанс.


Я хочу поблагодарить Готфрида Вильгельма Лейбница за отличные вычисления, а также за двоичную систему. Он был первым, кто понял, что можно поставить основание 2 в индийскую позиционную систему счисления. Он думал, что это замечательно. И он был прав.


Я хочу поблагодарить Джорджа Була — английского логика, который разработал алгебру, основанную только на двух значениях — true и false. Булевский тип данных назван в честь него.


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


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

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

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

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

Мы — дети Техути. Используем язык программирования для перевода чисел в магию.

---

Если вам понравился этот доклад Дугласа Крокфорда, приглашаем вас на два его новых выступления в рамках грядущей конференции HolyJS 2017 Moscow, которая пройдет в Москве 10 и 11 декабря.

• The Post JavaScript Apocalypse — это его первый доклад, где он расскажет о том, каким мог бы быть язык следующего за JS поколения, а также о новых полезных фишках в ES6.
• Managing Asynchronicity with RQ — второй доклад, рассказывающий о решении, которое призвано повысить простоту использования благодаря минимализму.

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

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

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



В основе статьи — доклад Дугласа Крокфорда (Douglas Crockford) с июньской конференции HolyJS 2017 в Санкт-Петербурге (презентацию доклада можно найти тут)

Пальцы

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

Инструменты

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

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

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

Счет

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

Письменность

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

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

Давайте рассмотрим подробнее некоторые исторические системы счисления.

Египет

Так выглядели числа в Египте.


У египтян была десятичная система. Для каждой степени 10 у них был предусмотрен свой иероглиф. Палка представляла единицу, кусок верёвки — 100, палец — 10000, а парень с поднятыми руками — миллион (это демонстрирует некоторую математическую изощренность, т.к. у них был символ, обозначающий не абстрактное понятие «много», а точно «миллион» — ни больше, ни меньше).

Египтяне придумали много других вещей: треугольник 3 на 4 на 5 с прямым углом (они знали, зачем этот угол нужен), действительно умную систему для работы с дробями. У них было приближение для числа Пи и много чего еще.

Финикия

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

Греция

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

Греки использовали тот же набор символов для записи чисел. Они взяли первые 9 букв алфавита для обозначения цифр с 1 по 9, следующие 9 букв — для десятков от 10 до 90, и еще 9 букв для сотен — от 100 до 900. Свою систему они передали римлянам.

Рим

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

Одна из проблем египетской системы заключалась в том, что для записи числа 99 требовалась последовательность из 18 символов. Римляне хотели сократить запись. Для этого они придумали символы, представляющие половину десяти или половину сотни (тысячи). Один у них был представлен символом I (или палкой), 10 — X (пучок палок, соединенных вместе), а 5 — V, что есть всего лишь X пополам.

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

Китай

Между тем в Китае творились действительно интересные вещи.


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

Индия

Больший скачок произошел в Индии.



Математики в Индии пришли к идее нуля — числа, которое ничего не представляло. И они догадались использовать его на позиционной основе. Для отображения чисел применялись всего 10 символов, но они могли быть объединены для создания любого числа. Это было действительно важной идеей.

Тиражирование идеи

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

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

Запись чисел и математика

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


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

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

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

Важная идея заключается в том, что индийские числа научили нас математике.



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

Целые числа

Данная система также допускала отрицательные числа.


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

Вещественные числа

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


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

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


Но с годами разделительный символ менялся.

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


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

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

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

Основание

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

Как это произошло? Они просто посчитали пальцы на обеих руках. И это сработало.

Но есть и другие культуры, которые записывали числа по-другому. Например, в Америке была система счисления с основанием 20. Знаете, как они до нее додумались? Полагаю, это очевидно: они посчитали пальцы не только на руках, но и на ногах. И это тоже сработало. У них была развитая цивилизация. Они выполняли достаточно много вычислений, но использовали основание 20.

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

Компромиссы: 60

Шумеры использовали основание 60. Да и мы все еще придерживаемся основания 60, верно? Мы так считаем наше время и делаем географические измерения. Географическим приложениям приходится использовать систему координат на базе системы счисления с основанием 60. Это добавляет ненужную сложность.

Как появилось основание 60? Я думаю, когда города росли, они поглощали много мелких поселений, объединяя их в большие. В какой-то момент они попытались объединить сообщество, которое использовало основание 10, с сообществом, которое взяло в качестве основания 12. Наверняка был какой-то король или комитет — кто-то должен был решить, как объединить их. Правильный вариант был — использовать основание 10. Второй вариант — развиваться с основанием 12. Но вместо этого они выбрали худший вариант из возможных — использовали основание, являющееся наименьшим общим кратным. Причина, по которой было принято такое решение, состоит в том, что комитет не мог решить, какой из вариантов лучше. Они пришли к компромиссу, который, по их мнению, похож на то, что все хотели. Но дело же не в том, кто и что хочет.

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

Двоичная система

Действительно интересная вещь, связанная с основанием, — появление двоичной системы. Мы можем взять индийскую систему и просто заменить 10 на 2.


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

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

• Знаковая величина (Signed magnitude representation). В этом случае мы просто добавляем дополнительный двоичный бит к числу и решаем, в каком из состояний этот бит соответствует положительному числу, а в каком — отрицательному. И неважно, поставим ли мы этот бит спереди или сзади (это всего лишь вопрос конвенции). Недостатком этого способа является присутствие двух нулей: положительного и отрицательного, что не имеет смысла, поскольку ноль не имеет знака.
  
• Первое дополнение (One’s complement), в котором мы выполняем операцию побитового нет для числа, чтобы сделать его отрицательным. Помимо двух нулей (положительного и отрицательного — как в предыдущем варианте) у этого представления присутствует проблема переноса: при обычном сложении двух чисел, представленных таким образом, для получения корректного результата необходимо в конце добавлять 1 бит. Но в остальном это работает.
  
• Второе дополнение (Two's complement), в котором удалось обойти проблему переноса. Отрицательное N представляется не побитовым отрицанием положительного N, а им же + 1. Помимо отсутствия проблемы переноса мы получаем только один нуль, что очень хорошо. Но при этом мы получаем дополнительное отрицательное число. И это проблема, потому что вы не можете получить абсолютное значение этого числа — вместо этого вы получите то же отрицательное число. Это потенциальный источник ошибок.
  

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


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

Types

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

int

У нас есть много языков, где под разными именами есть int32. Если мы сложим два числа int32, к какому типу будет относиться результат? Ответ — int33, потому что в результате сложения вы можете получить число, которое немного больше int32.

Здесь Java ошибается. Java говорит, что это int32.

Еще один пример — умножение int32 на int32. Что мы получим в результате? Похоже, int63.


Когда в результате обычного вычисления получается результат, который выходит за рамки типа, мы получаем переполнение. И наши CPU знают об этом. Например, в архитектуре Intel в ЦП есть флаг переноса, который содержит этот 33-й бит. Также на архитектуре Intel, если вы делаете умножение 32-битных чисел, вы получаете 64-битный результат. Т.е. предусмотрен регистр, который содержит необходимые вам «дополнительные» 32 бита. И есть флаг переполнения, который устанавливается, если требуется игнорировать высокий порядок умножения. Он сообщает, что произошла ошибка. К сожалению, Java не позволяет вам получать эту информацию. Она просто отбрасывает все, что является проблемой.

Что вообще должно происходить, при переполнении? Здесь есть несколько вариантов действий:

• мы можем хранить значение null, что, я думаю, очень разумно;
  
• или максимально возможную часть (насыщение — saturation). Это может быть разумно при обработке сигналов и в компьютерной графике. Однако вы не захотите так делать в финансовых приложениях;
  
• можно выдавать ошибку — машина должна вызвать исключение или что-то должно произойти. Софт должен понять, что в вычислениях произошла путаница и нужно исправить ситуацию;
  
• некоторые говорят, что программа должна остановиться. Это довольно резкая реакция, но такой вариант работал бы, если бы машина не просто останавливалась, а как-то сообщала, что что-то не так.
  

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

Разбиение чисел на значения из разных регистров

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

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

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

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

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


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

Вот как выглядит стандарт вычислений с плавающей запятой в двоичной системе:


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

Однако с этой записью есть проблема: в ней 0,1 + 0,2 не равно 0,3.


Результат близок, но он неправильный.

Давайте посмотрим, что происходит.


Представим числовой ряд. 0,1 — это приблизительно 1/16 + 1/32, но немного больше, поэтому нам понадобятся ещё несколько бит. По мере движения по числовому ряду мы получим бесконечно повторяющуюся серию 0011, похожую на то, что происходит с 1/3 в десятичной дроби.


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

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


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

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

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

А поскольку ни одно из наших чисел не представлено точно, все вычисления ошибочны! Это означает, что (A + B) + C не то же самое, что A + (B + C), что порядок, в котором вы выполняете вычисления, может изменить результат.

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

В то время были две школы вычислений:

• те, кто занимались научным трудом, писали на Фортране с использованием чисел с плавающей точкой в двоичной системе;
  
• те, кто занимались бизнесом, писали на Cobol, используя двоично-десятичный код (binary coded decimal, BCD). Двоично-десятичный код выделяет 4 бита для каждой цифры и ведет обычный подсчет в десятичной системе (используя обычную арифметику).
  

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

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

Проблема с типами

В большинстве современных языков программирования присутствует путаница из-за ошибочных типов данных. Например, если вы пишите на Java, каждый раз создавая переменную, свойство или параметр, вам нужно правильно выбрать тип из Bite, Char, Short, Int, Long, Float, Double. И если вы выберете неправильно, программа может не заработать. Причем ошибка проявится не сразу, и в тестах её не будет видно. Она покажет себя в будущем, когда произойдёт переполнение и связанные с этим плохие вещи.

Что может случиться? Одним из самых впечатляющих примеров был отказ Aryan 5. Это ракета, отправленная Европейским космическим агентством. Она сильно отклонилась от курса, а затем взорвалась через несколько секунд после старта. Причиной тому была ошибка в программном обеспечении, написанном на Ада. Здесь я перевел ошибку на Java:



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

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

DEC64

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

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

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

DEC64 может точно представлять десятичные дроби, содержащие до 16 цифр, чего вполне достаточно для большинства наших приложений. Вы можете представлять числа от 1*10^-27 до 3 с 143 нулями.

DEC64 очень похож на исходные числа с плавающей точкой, разработанные в 40-х годах. Число представлено в виде двух чисел, которые упакованы в 64-битное слово. Коэффициент представлен 56 битами, а показатель — 8 битами.


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

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

С форматом DEC64 я не надеюсь попасть в следующий JavaScript, поскольку это фундаментальное изменение. Зная как работает комитет, я не думаю, что это возможно. DEC64 поможет создателю следующего языка программирования (я надеюсь, что JavaScript не станет последним языком программирования — мы не можем оставить его детям; мы должны предложить им что-то другое).

Неопределенности и нули

=Давайте вернемся к числам.

Что такое 0/0?

• Большинство математиков скажут, что это значение не определено, подразумевая, что глупо так делать — такое выражение не имеет смысла (JavaScript определяет это как Undefined). Такая позиция хороша для математики, потому что там все происходит в теоретическом пространстве. Но это не работает для вычислений, потому что если кто-то может подать эти данные на вход машины, та должна как-то отреагировать (вы не можете сказать, что дизайн машины не определён — что-то должно произойти).
  
• Еще одна теория говорит, что машина должна загореться, потому что никто не будет в здравом уме пытаться делить 0 на 0, так что этого никогда не должно произойти. Но мы знаем, что это неправда. Потому что если что-то может произойти, это произойдет.
  
• Другая версия — это должно быть null или какое-то иное понятие, которое говорит, что это не значение. И это разумно.
  
• Еще одна школа считает, что результат должен быть нулевым. Есть математики, которые уверены в этом, но для большинства бизнес-задач такой результат не имеет смысла. Если в прошлом месяце мы продали 0 единиц товара, и общая прибыль по этим единицам составляла 0, какова была средняя прибыль за товар? 0?
  
• Некоторые люди говорят, что это 1, потому что N / N = 1.
  
• Когда-то я работал на мэйнфрейме, где результат был 2. Это была машина, которую создал Сеймур Крей — величайший компьютерный дизайнер в истории. Я ввел 0/0 и получил 2. Могу представить себе диалог в Control Data Corporation. Кто-то сказал: «Сеймур, есть проблема с вашей схемой деления!». «В чем проблема?». «Если кто-то разделит 0 на 0, получит 2!». И Сеймур говорит: «Послушай… Такой операции не должно быть. Ни один разумный человек никогда не должен этого делать. И если я включу дополнительную логику для этого случая, чтобы определить поведение машины, т.е. добавлю ещё одну проверку, она ухудшит производительность для всех, в том числе, для умных людей, которые не выполняют таких операций. И это сделает машину дороже. Я не собираюсь этого делать только из-за того, что какой-то идиот хочет разделить 0 на 0».
  

Также меня интересует, чему равно 0 * n для любого значения n.
Я думаю, что это 0. Но были компиляторы, которые, если встречали в умножении 0, не делали умножение вовсе. Это было большим плюсом к скорости. К сожалению, когда был создан стандарт записи чисел с плавающей точкой, такой подход был объявлен ошибочным, потому что если n является NaN, то результат 0 x NaN не равен нулю.

Почему мы вообще должны заботиться об этом?

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

Современные процессоры имеют очень длинные протоколы декодирования команд, которые занимают много циклов. Но они могут быстро перерабатывать множество инструкций, пока нет никаких условных переходов. Если же есть условный переход, все останавливается, пока не будет ясно, в какую сторону двигаться дальше. И это действительно замедляет работу. Есть способ написания кода, когда вы вместо выбора между двумя значениями (условия), выполняется дополнительное действие — умножение на 0 или 1, являющиеся результатом логической операции (того самого условия). Хотя это дополнительная работа, ее исполнение может быть быстрее, чем выполнение кода с условными переходами. Поэтому я рекомендую все операции с 0 (деление, умножение, деление с остатком) приравнивать к нулю.

Как и DEC64, эта идея предложена для следующего поколения прикладных языков программирования.

Вместо заключения

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


Я хочу начать с Леонардо Фибоначчи из Пизы. В конце XII века Леонардо посетил Аравию и узнал удивительные вещи, которые арабские математики воплотили через свою систему счисления — алгебру, геометрию, алгоритмы. Он привез их в Европу и написал книгу, которую опубликовал в 1202 году. В течение следующего столетия эта книга преобразовала Европу. Он создал базу для новых форм банковского дела, что привело к увеличению капитала, подпитывающего Ренессанс.


Я хочу поблагодарить Готфрида Вильгельма Лейбница за отличные вычисления, а также за двоичную систему. Он был первым, кто понял, что можно поставить основание 2 в индийскую позиционную систему счисления. Он думал, что это замечательно. И он был прав.


Я хочу поблагодарить Джорджа Була — английского логика, который разработал алгебру, основанную только на двух значениях — true и false. Булевский тип данных назван в честь него.


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


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

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

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

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

Мы — дети Техути. Используем язык программирования для перевода чисел в магию.

---

Если вам понравился этот доклад Дугласа Крокфорда, приглашаем вас на два его новых выступления в рамках грядущей конференции HolyJS 2017 Moscow, которая пройдет в Москве 10 и 11 декабря.

• The Post JavaScript Apocalypse — это его первый доклад, где он расскажет о том, каким мог бы быть язык следующего за JS поколения, а также о новых полезных фишках в ES6.
• Managing Asynchronicity with RQ — второй доклад, рассказывающий о решении, которое призвано повысить простоту использования благодаря минимализму.

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

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

Управление временем

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

TMetric Time Tracker
• Базовая версия: бесплатно
• Профессиональная версия: $4 за пользователя в месяц
• Бизнес-версия: $6 за пользователя в месяц



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

В приложении используется простая иерархия. Задачи формируют Проекты, объединяемые в Клиентов. Можно независимо отслеживать каждую категорию, так что можно точно узнать, сколько и на что было потрачено времени.

С помощью функции Workday Timeline можно быстро оценить, на что у вас уходит время в течение дня. Вы также можете объединиться со своими коллегами и отслеживать время каждого из вас с помощью фичи Team View. В приложении можно сгенерировать подробный отчёт о потраченном времени и заработанных на каждом проекте деньгах. Бизнес-владельцы могу настроить соотношения разных типов работы и без затруднений вычислять зарплаты сотрудников.
TMetric позволяет очень легко отслеживать отдельно оплачиваемое и неоплачиваемое время, так что вы сможете держать руку на пульсе своих расходов и доходов. А для группирования задач или проектов можно использовать удобную систему тегов.

Наконец, приложение легко интегрируется с популярными сервисами управления проектами, вроде Trello, Asana, Jira, Todoist и многими другими, так что вы можете использовать эту связку как одно полное решение.

ManicTime

• Базовая версия: бесплатно
• Профессиональная версия: $67 за лицензию в год



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

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

Timely
• Индивидуальная версия: $14 за пользователя в месяц
• Корпоративная версия: $21 за пользователя в месяц
• Энтерпрайз-версия: $49 за пользователя в месяц



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

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

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

Чек-листы

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

Wunderlist
• Базовая версия: бесплатно
• Профессиональная версия: $4,99
• Бизнес-версия: $4,99 за пользователя



Wunderlist — популярное приложение, и настолько качественное, что Microsoft купила компанию за $200 миллионов. Программ простая и небольшая, позволяет быстро создавать список задач и отслеживать их выполнение. В Wunderlist есть ограниченная поддержка повторяющихся задач, и можно даже сотрудничать с другими пользователями.

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

Todoist
• Базовая версия: бесплатно
• Премиум-версия: $29 в год
• Бизнес-версия: $29 за пользователя в год



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

Вы можете не только добавлять задачи, но и отправлять электронные письма посредством браузерных плагинов для Gmail, Thunderbird или Outlook. Как и Wunderlist, Todoist — кроссплатформенный продукт и может работать на любом устройстве.

У Todoist есть замечательное свойство, позволяющее добавлять задачи, просто набирая характерные фразы вроде «Среда в 11 часов» или «каждую пятницу в 16 часов».

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

Remember the Milk
• Базовая версия: бесплатно
• Профессиональная версия: $39.99/year



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

Прежде всего, RTM с самого начала использует для создания задач естественный язык. Достаточно сказать что-нибудь вроде «отправить письмо Ивану в 9 утра в среду», и задача будет добавлена в список.

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

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

Планировщики

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

Calendly
• Базовая версия: бесплатно
• Премиум-версия: $8 за пользователя в месяц
• Профессиональная версия: $12 за пользователя в месяц



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

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

Google Calendar
• Использование: бесплатно



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

Как и прочие продукты Google, Calendar отличается простым и понятным интерфейсом, позволяющим очень легко назначать события и задачи. Если вы пользуетесь G Suite for Businesses, то имейте в виду, что Messages может автоматически создавать в календаре события на основе текста ваших писем.

Для разных типов задач можно создавать разные календари. Например, можно сделать календарь для работы, для домашних дел, для выходных, для хобби и так далее. Все задачи будут отображаться в главном интерфейсе, но кликнув на вкладку My Calendars можно переключиться на отдельные календари. Ваши коллеги могут делиться с вами своими календарями. Чтобы добавить их в свой список, введите имя/почту человека в “Other Calendars”.

Наконец, у Google Calendar прекрасная система напоминаний, которая найдёт вас на настольном компьютере, ноутбуке или мобильном устройстве. При этом сами напоминания могут быть однократными и повторяющимися.

Doodle
• Базовая версия: бесплатно
• Личная версия: $39 за пользователя в год
• Бизнес-версия: $69 за пользователя в год



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

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

Пользователи личной и бизнес-версии могут создавать свои поддомены на зашифрованном с помощью SSL сайте Doodle.com. Также можно настраивать списки участников и рассылать автоматические уведомления.

Управление проектами

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

Trello
• Базовая версия: бесплатно
• Бизнес-версия: $9,99 за пользователя в месяц
• Энтерпрайз-версия: $20,83 за пользователя в месяц



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

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

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

Asana
• Базовая версия: бесплатно
• Премиум-версия: $9,99 в месяц
• Энтерпрайз-версия: по запросу



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

Asana поделена на три уровня. Задачи — нижний уровень. Их можно назначать конкретным людям, добавлять комментарии, примечания, создавать подзадачи. Проекты — это списки задач. Их можно организовывать и менять им приоритеты в рамках проектов. Рабочие зоны (Workspaces) — это как доски в Trello, здесь вы можете тасовать свои проекты.

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

Заключительные мысли

Хотя все эти приложения — отличные инструменты, сами по себе они не решат ваших проблем с продуктивностью. Добавление задачи в чек-лист не гарантирует её выполнения.

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

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

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