Здесь описаны мои исследования, как сделать ревизию кода в команде более приятным занятием, которое может дать новый опыт всем участникам. У нас полностью географически распределённая команда, все коммуникации выполняются через интернет, и зачастую асинхронно. Мы используем Trello для описания возможностей продуктов, поодиночке создаём код, отправляем в GitHub пулл-реквесты, а также пользуемся встроенной в GitHub функцией их ревью. Это отличается от просмотра кода лицом к лицу в офисе и даже по видеочату. Если не подходить к делу всерьёз, то асинхронная и письменная ревизия кода может стать причиной катастрофы в команде, приведя к ухудшению взаимодействия и сотрудничества. Но если все участники будут стараться делать всё хорошо, то такой подход может работать очень эффективно. Для чего нужно ревью кода? Прежде чем начать рассуждать о том, как делать и как не делать ревью, полезно подумать о том, для кого в компании оно нужно, и в соответствии с этим вырабатывать требования. И хорошо бы не забывать, что ревью — это не просто поиск багов и проблем в структуре кода. Ревью нужно для улучшения качества кода и морального духа в команде. Анализ кода друг друга — один из главных путей взаимодействия между разработчиками во время обычного рабочего дня. Это должен быть вдохновляющий процесс, чтобы все участники ждали его и активно участвовали в нём. Вот основные задачи, решаемые с помощью ревизий: Создание внутренней культуры команды. Ревью — это один из основных процессов, который подразумевает наличие командной культуры. И если участникам неприятно участвовать в ревью, значит, внятной командной культуры нет. Ревизии должны создавать позитивную атмосферу, терпимость и дружественность. Улучшение рабочих взаимоотношений благодаря возможности чаще разговаривать с коллегами. Снятие напряжённости в отношениях с помощью положительных отзывов о чужом коде. Обучение. Проводящий ревью может узнать для себя новые вещи из чужого кода, а автор — из отзыва. Выход за границы своей зоны ответственности, позволяющий всем участникам команды анализировать разные части кода, ознакомляясь со всей кодовой базой. Наставничество и образование. Ревью — это возможность для более опытных участников стать наставниками и обучать других. Но имейте в виду, что, поскольку время уже прошло и код написан, ревью — не всегда лучшее время для обучения. Разработчики должны совместно работать над техническим проектом как до, так и во время создания кода. Качество кода. И наконец, качество (включая баги, удобство в сопровождении, документацию, организацию, архитектуру, удобство использования продукта…). Что не надо делать при ревью Возможно, эта часть покажется вам довольно негативной, но зато после неё идёт часть с приятными вещами! Есть много разных способов сделать ревью кода неудачным. Воинственные, злые и непредсказуемые комментарии способны лишить команду удовольствия от работы и превратить ревизию в эмоционально тяжёлую обязанность. Понимание, чего следует избегать при ревью, как раз и отличает ценную часть работы команды от жестокого и неприятного наказания. Эрик Дитрих, «Чего нужно избегать при ревью кода» Не проводите ревью формально и с минимальными комментариями (a.k.a. узнать, насколько плохо думают о вас коллеги) Не нужно всего лишь указывать на ошибки, ничего к этому не добавляя. Разработчики тратят много времени на код и гордятся им, и ревью — их шанс продемонстрировать свою работу. А при формально-минималистичном подходе всё, на что вы можете надеяться, — это комментарии в стиле «Выглядит неплохо, смерджил». Такое ревью достойно названия «Узнай, насколько плохо о тебе думают». Невнятное и непродуманное общение может привести к долговременным неприятным последствиям. Командная культура испортится, что снизит продуктивность. При этом разработчики часто получают отзывы вроде «похоже, эта порка придумана специально для того, чтобы выбить из них дух», а сами ревизии превращаются в «ментальные соревнования, в которых люди стреляют по цели… а цель — это разработчик, написавший код». Не думайте, что достаточно лишь «критиковать код, а не кодера» Это один из самых популярных советов: критикуйте код, а не кодера. Он хорош (если вы критикуете коллегу, а не его код, то у вас проблемы). Но этого недостаточно. Написание кода — творческий процесс, в который разработчик вкладывает сердце и душу. И если вы жестоко и тупо критикуете чей-то код, то тем самым вы критикуете самого человека. Нужно уметь критиковать. Найдите более позитивные способы анализа и вносите свои предложения, как улучшить код. Следите за тоном Не переходите на личности. Фразы вроде «Почему ты сделал именно так?» воспринимаются как нападки. Плохой вариант: «То, как ты написал эту функцию, затрудняет её чтение, добавь больше комментариев» (личное обращение подразумевает, что человек что-то сделал не так). Лучше скажите: «Тебе не кажется, что стоит добавить в код дополнительные комментарии, это облегчит чтение функции?» (звучит гораздо корректнее и позволяет сосредоточиться на улучшении кода). Обойдитесь без требовательных или вызывающих выражений. Избегайте фраз, смысл которых заключается в «ты неправ». Не говорите людям, что они неправы или что они сказали/сделали что-то не то, им будет неприятно. В таких случаях люди могут уходить в защиту, перестают долго и творчески работать и учиться. Избегайте фраз наподобие: «Так не сработает» «Совершенно неправильно» «Почему ты просто не … ?» Не сгущайте краски. Вы же не хотите, чтобы на критику обижались за необоснованность или преувеличенность? Не говорите «всегда», «никогда», «бесконечно», «ничего». Не надо оскорблений. Избегайте ругательств вроде «дурак» или «идиот», даже если лично вы не считаете их обидными. У подобных слов есть определённый спектр значений, и он точно не улучшит настроение автора кода. Не используйте нетерпеливых или пассивно-агрессивных оборотов. Всегда будьте сдержанны и дружелюбны, избегайте неприятных фраз, демонстрирующих раздражение и заставляющих людей чувствовать, что они плохо справляются: «Ещё раз повторяю: здесь нужно…» «Как я уже говорил…» Не подливайте масла в огонь. Человеку может быть неприятно получить от кого-то комментарий с критикой, а под ним ещё несколько с «+1» или нравоучениями по тому же поводу. К тому же многочисленная критика способна просто запутать. Не будьте непрошеным советчиком Сдерживайте себя и не предлагайте внести в код все изменения, которые вы хотели бы внести. Вы можете деморализовать автора кода, предложив поменять столько, что придётся всё переписать. Так что выбирайте только самое важное и лучшее. Одна из задач ревью — найти и исправить баги и проблемы в структуре кода. А вовсе не заставить автора написать код так, как это сделали бы вы. Не забывайте, что в программном обеспечении многие вещи можно решить по-разному, в зависимости от вкусов разработчика, и у каждого подхода есть свои плюсы и минусы. Собираясь предложить очередную правку, спросите себя: может быть, это просто моё мнение? Если автор выбрал другие способы, обосновав свой выбор, то лучше поддержите его. Уважайте право автора на собственные решения. Даже если кто-то написал код не так, как это сделали бы вы, то это ещё не означает, что код написан неправильно. Главное — качественный, удобный в сопровождении код. Если он удовлетворяет этим критериям и принятым в команде правилам, то этого достаточно. Роберт Бог, «Эффективные ревью без боли» Вы никогда не сможете заставить других написать именно такой код, какой написали бы вы, не надо и пытаться (если вам это так важно, то лучше сразу напишите код сами). Эрик Дитрих, «Чего нужно избегать при ревью кода» Не нарушайте правило «Никаких сюрпризов» Избегайте неожиданностей. Создайте для команды общее задокументированное соглашение о pull request’ах и стандартах кода и во время ревью опирайтесь на него, а не на своё мнение. Не говорите только для того, чтобы услышать свой голос Прежде чем написать отзыв, подумайте, чего вы хотите этим достичь. Все ли ваши комментарии необходимы? Помните, что вы пытаетесь конструктивно помочь, а не просто высказать свою точку зрения. Прежде чем опубликовать отзыв, перечитайте свои комментарии и спросите себя, все ли они действительно полезны и важны? Лишние удалите. Лучше анализировать свои заметки после просмотра кода, постфактум. Пока вы разбираетесь с кодом, пишите сколько угодно комментариев, а потом спокойно просмотрите их и решите, что оставить. Оставлять комментарии только для того, чтобы подчеркнуть свою правоту, не всегда полезно (или разумно). Иногда лучше держать своё мнение при себе, чтобы сохранить длительные хорошие отношения с человеком. Кэтрин Дэниелс, «Как давать и получать отзывы» Вы не обязаны находить проблемы в ходе каждого ревью Если код хорош и может быть влит в кодовую базу без изменений, то всё прекрасно! Что надо делать при ревью Ревью можно улучшить. Как именно? Ниже вы прочтёте предложения, собранные в интернете. Хвалите хороший код Не жалейте времени на то, чтобы похвалить сильные стороны кода, прежде чем указывать на недостатки и вносить предложения. Человеческая природа такова, что нам нужно знать о своих успехах, а не только о неудачах. Разработка — это творческий процесс, в который люди вкладывают душу, они часто принимают многое близко к сердцу. Поэтому похвалы для них ещё более важны. Роберт Бог, «Эффективные ревью без боли» Вы же хотите, чтобы участники команды воспринимали ревью как приятный и полезный опыт, а не как чистое критиканство. Положительные отзывы снижают напряжённость в отношениях и помогают людям лучше реагировать на критику. Важно писать позитивные комментарии так, чтобы это не выглядело слащаво или фальшиво. Не должно создаваться впечатление, что вы просто стараетесь подсластить пилюлю. Избегайте сомнительных комплиментов. Фразы вроде «Хорошая работа, но…» (дальше — список изменений, которые вы предлагаете сделать) выглядят наигранными. Как сделать похвалы более честными? Оцените большинство хороших частей кода и другие аспекты и постарайтесь сказать, почему они вам понравились. Вникая в чужой код, оставляйте в комментариях свой «монолог на ходу». «Ага, понял, что это делает… Хорошо, подключается сюда и вызывает это, замечательно… а эта часть зависит от тех двух, отлично». Ход мыслей другого программиста, который разбирается в твоём коде, — ещё одна форма проверки работы. А когда тебе попадаются части кода, которые ты не понимаешь, можно попросить объяснить. Сначала — положительные моменты Сразу задайте настроение, в первую очередь рассказав о том, что вам понравилось. Теперь это легко можно сделать благодаря новым возможностям ревью кода на GitHub, создавая многострочные комментарии и публикуя их скопом (вместо публикации по мере сохранения), а также делая краткое резюме (отображается в начале отзыва) до внесения комментариев: Избегайте неизбежных обвинений Спрашивайте, а не говорите. Лучше задавать вопросы, а не делать заявления. Заявление — это обвинение. Фраза «Здесь ты не соблюдал стандарты» — это обвинение, намеренное или нет. Задайте вопрос: «Почему ты использовал здесь такой подход?» Роберт Бог, «Эффективные ревью без боли» Если задавать вопросы, то это улучшит общий настрой, восприятие ревью изменится благодаря приглашению к диалогу и обучению, а автор кода с удовольствием объяснит причину или поищет более удачный способ решения. В идеале в ответ на корректный вопрос автор сам найдёт баг или предложит внести в код улучшения. Если вы видите какие-то моменты, которые могут быть ошибками, не надо сразу говорить людям, что они неправы. Обычно достаточно спросить: «Что будет, если я передам этому методу ноль?», и человек наверняка сам скажет: «У меня были сомнения, исправлю». Позволить ему самому решить проблему и предложить улучшить код — гораздо лучше, чем давать указание по исправлению несовершенств. Эрик Дитрих, «Используйте ревью кода для казни» Плохо: «Здесь ты не соблюдал стандарты» «А — неправильно, надо использовать В» «Запутанный код» «Ты не инициализировал эти переменные» Хорошо: «Почем ты выбрал здесь такое решение?» «Почему ты использовал A вместо B?» «Эта часть мне непонятна. Можешь объяснить?» «Я не нашёл, где инициализируются эти переменные» Избегайте обвинительного «почему». Как и утверждения, вопросы «почему» тоже могут звучать обвинительно, так что без них будет лучше. Плохо: «Почему здесь ты не следовал стандартам?» «Почему ты просто не …?» Хорошо: «По какой причине ты решил отойти здесь от стандартов?» «Чем ты руководствовался, когда …?» Будьте скромнее Задавайте вопросы, а не требуйте. Вместо того чтобы сказать автору, какие нужны изменения, задайте ему вопрос о коде или внесите предложение и спросите автора, что он думает по этому поводу. Так вы передаёте мяч на его сторону поля и выказываете уважение его свободе воли, давая автору шанс объяснить своё решение или высказаться, считает ли ваше предложение полезным для кода. Вместо «Давай назовём эту переменную username, потому что иначе непонятно» лучше перефразировать предложение в виде вопроса: «Может быть, назвать её username? Текущее имя выглядит не слишком понятно для меня, потому что оно также используется в другом контексте в someotherfile.js.». Дэниел Бадер, «7 способов избежать ухудшения отношений при ревью кода» Когда вы что-то предлагаете, обязательно объясняйте причину, по которой это изменение может улучшить код. Используйте личные примеры. Покажите автору кода, что не только он совершал такую ошибку. Это отличный способ смягчить критику: «Мне самому это тяжело далось…», «Я делал то же самое». Не на каждый вопрос нужно отвечать. Примите для себя сразу, что не на каждый ваш вопрос автор кода должен дать ответ. Так вы сможете задавать в своём отзыве вопросы, заставляющие задуматься. На них необязательно отвечать, чтобы влить код в кодовую базу, но зато они подстёгивают мысль разработчика и в долгосрочной перспективе повышают качество его работы. Не нарушайте правило «Никаких сюрпризов» Воспользуйтесь чек-листом: Наверняка каждый участник вашей команды раз за разом совершает одни и те же десять ошибок. Причём труднее всего обнаружить пропуски каких-то элементов. Так что чек-лист — самый простой способ избежать наиболее распространённых ошибок и снизить вероятность пропусков. SmartBear, «Лучшие методики ревью кода» Конечно, чек-лист не может покрыть все возможные случаи. Но в хороший список достаточно включить все требования, которым должен удовлетворять pull request, чтобы быть слитым с кодовой базой. Это полезный инструмент и для кодера, и для рецензента. Чек-лист может помочь улучшить код, сделать его более последовательным, избежать нарушения правил и стандартов. Новым участникам будет очень полезно законспектировать требования к коду, прежде чем отправлять свой первый pull request и проводить первую ревизию. Пример чек-листа, с которого можно начать: В вашей ветке должна содержаться одна логически отдельная операция и никаких не связанных с ней изменений. У вас должны быть качественные commit-сообщения. См. <ссылка на руководство по commit-сообщениям>. Ваша ветка должна содержать новые или изменённые тесты для всего нового или изменённого кода. Все тесты должны выполняться в ветке. См. <ссылка на руководство по написанию тестов>. Ваша ветка должна содержать новую или обновлённую документацию для всего нового или обновленного кода. См. <ссылка на руководство по написанию документации>. Ваша ветка должна быть актуальна мастер-ветке и сливаться без конфликтов, поэтому сделайте ребейз до pull request’а. Весь новый код должен удовлетворять принятым у нас архитектурным требованиям и руководствам по Python, JavaScript, HTML и CSS-стилям. См. <ссылка на руководства по архитектурам и стилям>. Если новый код содержит изменения в схеме базы данных, то он должен включать и миграцию базы данных. См. <ссылка на руководство по миграции базы данных>. Если код содержит изменения, нарушающие обратную совместимость с плагинами, API-клиентами или темами, то насколько необходимы такие изменения? Эффект от таких изменений достаточно велик для отказа от совместимости? Внесён ли в список изменений отказ от обратной совместимости? Добавляет ли новый код какие-то зависимости (например, импортированы новые сторонние модули)? Если да, то проводилась ли оценка новых зависимостей, были ли они добавлены в соответствии с правильной процедурой? См. <ссылка на руководство по обновлению зависимостей>. Тестировался ли код с рабочими данными? См. <ссылка на получение рабочих данных в руководстве разработчика>. Если изменился пользовательский интерфейс, то проводилось ли тестирование на экранах разного размера и в разных браузерах? См. <ссылка на руководство по адаптивному дизайну>. Если изменился пользовательский интерфейс, то удовлетворяет ли он требованиям по доступности? См. <ссылка на руководство по доступности>. Если появились новые строковые переменные, видные пользователям, то были ли они интернационализированы? См. <ссылка на руководство по интернационализации>. Используйте исчерпывающе задокументированные стандарты программирования: Стандарты программирования — это общее соглашение, заключаемое между разработчиками. Набор обязательных для всех рекомендаций по написанию качественного и удобного в сопровождении кода. Стандарты — фундамент ревью, потому что во время ревью мы проверяем код на соответствие стандартам. Вместо того чтобы предъявлять к коду требования, не входящие в стандарты, сделайте запрос на их включение в список рекомендаций. Без доступного всей команде эталонного проекта стандартов разработчики могут даже не понимать, где обнаружатся проблемы при следующем ревью. А это не добавляет эффективности их работе. Стандарты должны быть исчерпывающими. Можно опираться на стиль форматирования кода PEP 8, но это недостаточно полный стандарт для использования во время ревью. Анализируйте то, что нужно, а остальным займутся инструменты Во время ревью практически никогда не должны возникать проблемы с форматированием кода. Ревизии должны провоцировать появление продуктивных мыслей и дискуссий, а траты времени на стиль и форматирование в этом не помогут. Для подобных вещей используйте инструменты, например линтеры и средства автоматического форматирования. Заключение Это статья о том, как давать положительные заключения и правильно критиковать, как успешно вносить предложения во время ревью кода. Я предлагаю вам сделать сжатую версию этого руководства с выделенными ключевыми моментами и раздать её каждому участнику команды. Положите инструкцию в общий репозиторий, чтобы любой мог начать её разбор и предложить свои изменения, и тогда вся команда будет вовлечена в обсуждение. Также рекомендую подумать о том, как у вас создаётся код, который потом попадает на ревью. Вероятно, вы хотите, чтобы кодер и рецензент имели похожие представления о техническом дизайне до того, как код окажется на ревью. Заранее решите, кто будет писать код для конкретной фичи, а кто будет рецензировать, и поощряйте их работать вместе, чтобы эти двое обсуждали структуру кода и его промежуточные варианты, прежде чем проверять финальную версию. Нам же нужна качественная архитектура (две головы лучше), но также нужно избегать излишних дебатов во время анализа, когда оба разработчика предлагают совершенно разные решения (одному из них придётся полностью переписать уже готовый код). Если ещё до ревью между автором и рецензентом установится крепкое сотрудничество, то во время ревью, скорее всего, всплывёт лишь несколько мелких проблем.

В данной статье я постарался раскрыть назначение VMware Virtual SAN, принципы её работы, требования, возможности и ограничения данной системы, основные рекомендации по её проектированию. Концепция Virtual SAN VMware Virtual SAN (далее vSAN) представляет собой распределенную программную СХД (SDS) для организации гипер-конвергентной инфраструктуры (HCI) на базе vSphere. vSAN встроен в гипервизор ESXi и не требует развертывание дополнительных сервисов и служебных ВМ. vSAN позволяет объединить локальные носители хостов в единый пул хранения, обеспечивающий заданный уровень отказоустойчивости и предоставляющий свое пространство для всех хостов и ВМ кластера. Таким образом, мы получаем централизованное хранилище, необходимое для раскрытия всех возможностей виртуализации (технологии vSphere), без необходимости внедрения и сопровождения выделенной (традиционной) СХД. vSAN запускается на уровне кластера vSphere, достаточно запустить соответствующий сервис в управлении кластером и предоставить ему локальные носители хостов кластера – в ручном или автоматическом режиме. vSAN встроен в vSphere и жёстко привязан к ней, как самостоятельный продукт SDS, способный работать вне инфраструктуры VMware, существовать не может. Аналогами и конкурентами vSAN являются: Nutanix DSF (распределенное хранилище Нутаникс), Dell EMC ScaleIO, Datacore Hyper-converged Virtual SAN, HPE StoreVirtual. Все эти решения совместимы ни только с VMware vSphere, но и с MS Hyper-V (некоторые и с KVM), они предполагают установку и запуск на каждом хосте HCI служебной ВМ, необходимой для функционирования SDS, в гипервизор они не встраиваются. Важным свойством любой HCI, в т.ч. VMware vSphere+vSAN, является горизонтальная масштабируемость и модульность архитектуры. HCI строится и расширяется на базе идентичных серверных блоков (хостов или узлов), объединяющих вычислительные ресурсы, ресурсы хранения (локальные носители) и сетевые интерфейсы. Это может быть commodity-оборудование (серверы x86, в т.ч. брэндовые), поставляемое отдельно, либо уже готовые эплаенсы (например, Nutanix, vxRail, Simplivity). Комплексное ПО (например, vSphere+vSAN+средства_оркестровки_VMware) позволяет создать на базе этих блоков программно-определяемый ЦОД (SDDS), включающий среду виртуализации, SDN (программно-определяемая сеть), SDS, средства централизованного управления и автоматизации/оркестровки. Конечно, нельзя забывать про необходимость выделенного физического сетевого оборудования (коммутаторы), без которого невозможно взаимодействие между хостами HCI. При этом для организации сети целесообразно использовать leaf-spine архитектуру, оптимальную для ЦОД. vSAN поднимается на уровне кластера хостов ESXi под управлением vCenter и предоставляет распределенное централизованное хранилище хостам данного кластера. Кластер vSAN может быть реализован в 2х вариантах: • Гибридный – флэш-накопители используются в качестве кэша (cache layer), HDD обеспечивают основную ёмкость хранилища (capacity layer). • All-flash — флэш-накопители используются на обоих уровнях: cache и capacity. Расширение vSAN-кластера возможно путем добавления носителей в существующие хосты либо путем установки новых хостов в кластер. При этом необходимо учитывать, что кластер должен оставаться сбалансированным, это значит, что в идеале состав носителей в хостах (и сами хосты) должен быть идентичным. Допустимо, но не рекомендуется, включать в кластер хосты без носителей, участвующих в ёмкости vSAN, они также могут размещать свои ВМ на общем хранилище vSAN-кластера. Сравнивая vSAN с традиционными внешними СХД следует отметить, что: • vSAN не требует организации внешнего хранилища и выделенной сети хранения; • vSAN не требует нарезки LUN-ов и файловых шар, презентования их хостам и связанной с этим настройки сетевого взаимодействия; после активации vSAN сразу становится доступной всем хостам кластера; • передача данных vSAN осуществляется по собственному проприетарному протоколу; стандартные протоколы SAN/NAS (FC, iSCSI, NFS) для организации и работы vSAN не нужны; • администрирование vSAN осуществляется только из консоли vSphere; отдельные средства администрирования или специальные плагины для vSphere не нужны; • не нужен выделенный администратор СХД; настройка и сопровождение vSAN осуществляется администратором vSphere. Носители и дисковые группы На каждом хосте кластера vSAN должно быть минимум по одному кэш-носителю и носителю данных (capacity или data disk). Данные носители внутри каждого хоста объединяются в одну или несколько дисковых групп. Каждая дисковая группа включает только один кэш-носитель и один или несколько носителей данных для постоянного хранения. Носитель, отданный vSAN и добавленный в дисковую группу, утилизируется полностью, его нельзя использовать для других задач или в нескольких дисковых группах. Это касается как кэш-носителя, так и capacity дисков. vSAN поддерживает только локальные носители, либо диски, подключенные по DAS. Включение в пул хранения vSAN хранилищ, подключенных по SAN/NAS, не поддерживается. Объектное хранилище vSAN представляет собой объектное хранилище, данные в нем хранятся в виде «гибких» (flexible) контейнеров, называемых объектами. Объект хранит внутри себя данные или мета-данные, распределенные по кластеру. Ниже перечислены основные разновидности объектов vSAN (создаются отдельно для каждой ВМ): Таким образом, данные каждой ВМ хранятся на vSAN в виде множества перечисленных выше объектов. В свою очередь каждый объект включает в себя множество компонентов, распределенных по кластеру в зависимости от выбранной политики хранения и объема данных. Управление хранением данных на vSAN осуществляется с помощью механизма SPBM (Storage Policy Based Management), под воздействием которого находятся все хранилища vSphere начиная с версии 6. Политика хранения задает количество допустимых отказов (Number of failures to tolerate), метод обеспечения отказоустойчивости (репликация или erasure coding) и количество страйпов для объекта (Number of disk stripes per object). Заданное политикой количество страйпов определяет число носителей данных (capacity), по которым будет размазан объект. Привязка политики к конкретной ВМ или её диску определяет количество компонентов объекта и их распределение по кластеру. vSAN допускает изменение политики хранения для объектов на-горячую, без остановки работы ВМ. При этом в фоне запускаются процессы реконфигурации объектов. При распределении объектов по кластеру vSAN контролирует, чтобы компоненты, относящиеся к разным репликам объекта и компоненты-свидетели (witness), разносились по разным узлам или доменам отказа (серверная стойка, корзина или площадка). Witness и кворум Свидетель (witness) – это служебный компонент, не содержащий полезных данных (только метаданные), его размер равен 2-4МБ. Он выполняет роль тайбрейкера при определении живых компонентов объекта в случае отказов. Механизм вычисления кворума в vSAN работает следующим образом. Каждый компонент объекта получает определенное число голосов (1 и более). Кворум достигается и объект считается «живым» если мы имеем полную реплику данных, либо доступно более половины (50%) компонентов объекта или его голосов. Такой механизм вычисления кворума позволяет распределить компоненты объекта по кластеру таким образом, что можно обойтись без создания свидетеля. Virtual SAN datastore После включения сервиса vSAN в кластере vSphere появляется одноименное хранилище (datastore), на весь кластер vSAN оно может быть только единственным. Благодаря механизму SPBM, описанному выше, в рамках единого хранилища vSAN каждая ВМ или её диск может получить необходимый её уровень сервиса (отказоустойчивость и производительность) путем привязки к нужной политике хранения. vSAN datastore доступно всем хостам кластера, вне зависимости от наличия у хоста локальных носителей, включенных в vSAN. При этом хостам кластера могут быть доступны хранилища (datastore) других типов: VVol, VMFS, NFS. vSAN datastore поддерживает Storage vMotion (горячая миграция дисков ВМ) с хранилищами VMFS/NFS. В рамках одного сервера vCenter можно создавать несколько кластеров vSAN. Поддерживается Storage vMotion между кластерами vSAN. При этом каждый хост может быть участником только одного кластера vSAN. Совместимость vSAN с другими технологиями VMware vSAN совместима и поддерживает большинство технологий VMware, в т.ч. требующих общего хранилища, в частности: vMotion, Storage vMotion, HA, DRS, SRM, vSphere Replication, снапшоты, клоны, VADP, Horizon View. vSAN не поддерживает: DPM, SIOC, SCSI reservations, RDM, VMFS. Аппаратные требования vSAN Требования к устройствам хранения Носители, контроллеры, а также драйверы и firmware должны быть сертифицированы под vSAN и отображаться в соответствующем листе совместимости VMware (секция Virtual SAN в VMware Compatibility Guide). В качестве storage-контроллера может использоваться SAS/SATA HBA или RAID-контроллер, они должны функционировать в режиме passthrough (диски отдаются контроллером как есть, без создания raid-массива) или raid-0. В качестве кэш-носителей могут использоваться SAS/SATA/PCIe –SSD и NVMe носители. В качестве носителей данных могут использоваться SAS/SATA HDD для гибридной конфигурации и все перечисленные выше типы флэша (SAS/SATA/PCIe –SSD и NVMe) для all-flash конфигурации. Требования к ОЗУ и ЦПУ Объем памяти хоста определяется количеством и размером дисковых групп. Минимальный объем ОЗУ хоста, необходимый для поддержки максимальной конфигурации дисковых групп (5 дисковых групп по 7 носителей данных), равен 32ГБ. vSAN утилизирует порядка 10% ресурсов процессора. Требования к сети Выделенный адаптер 1Гбит/с для гибридной конфигурации Выделенный или совместно используемый адаптер 10Гбит/с для all-flash конфигурации Необходимо разрешить трафик мультикаст в подсети vSAN Загрузочные носители Для загрузки хостов с vSAN могут использоваться локальные USB или SD носители, а также SATADOM. Первые 2 типа носителей не сохраняют логи и трэйсы после перезагрузки, поскольку их запись осуществляется на RAM-диск, а последний сохраняет, поэтому рекомендуется использовать SATADOM-носители SLC-класса, обладающие большей живучестью и производительностью. Конфигурационные максимумы vSAN 6.5 Максимум 64 хоста на кластер vSAN (и для гибрида и для all-flash) Максимум 5 дисковых групп на хост Максимум 7 capacity-носителей на дисковую группу Не более 200 ВМ на хост и не более 6000 ВМ на кластер Не более 9000 компонентов на кластер Максимальный размер диска ВМ – 62ТБ Максимальное количество носителей в страйпе на объект – 12 Технологические особенности VMware Virtual SAN Планирование состава кластера vSAN Минимальное количество хостов кластера vSAN определяется числом допустимых отказов (параметр Number of failures to tolerate в политике хранения) и определяется по формуле: 2*number_of_failures_to_tolerate + 1. При условии отработки 1 отказа vSAN допускает создание 2х- и 3х- узловых кластеров. Объект и его реплика размещаются на 2х хостах, на 3м размещается свидетель. При этом появляются следующие ограничения: • при падении 1 хоста нет возможности ребилда данных для защиты от нового отказа; • при переводе 1 хоста в режим обслуживания нет возможности миграции данных, данные оставшегося хоста на это время становятся незащищенными. Это обусловлено тем, что ребилдить или мигрировать данные попросту некуда, нет дополнительного свободного хоста. Поэтому оптимально если в кластере vSAN используется от 4х хостов. Правило 2*number_of_failures_to_tolerate + 1 применимо только при использовании Зеркалирования для обеспечения отказоустойчивости. При использовании Erasure Coding оно не работает, подробно это описано ниже в разделе «Обеспечение отказоустойчивости». Для того, чтобы кластер vSAN был сбалансированным, аппаратная конфигурация хостов, в первую очередь это касается носителей и storage-контроллеров, должна быть идентичной. Несбалансированный кластер (разная конфигурация дисковых групп хостов) поддерживается, но заставляет мириться со следующими недостатками: • неоптимальная производительность кластера; • неравномерная утилизация ёмкости хостов; • отличия в процедурах сопровождения хостов. Допускается размещение ВМ с сервером vCenter на vSAN датасторе, однако это приводит к рискам, связанным с управлением инфраструктурой при проблемах с vSAN. Планирование кэша vSAN Рекомендуется планировать размер кэша с запасом для возможности расширения capacity уровня. В гибридной конфигурации 30% кэша выделяется на запись и 70% на чтение. All-flash конфигурация vSAN использует всю ёмкость кэш-носителей на запись, кэша на чтение не предусмотрено. Рекомендуемый размер кэша должен быть не менее 10% от реальной ёмкости ВМ до репликации, т.е. учитывается полезное пространство, а не реально занятое (с учетом репликации). В гибридной конфигурации дисковая группа будет утилизировать всю ёмкость установленного в неё флэш-носителя, при этом его максимальный объем не ограничен. В all-flash конфигурации дисковая группа не может использовать более 600ГБ ёмкости установленного флэш-носителя, поэтому в таких кластерах нецелесообразно использовать кэш-носители объемом более 600-800ГБ, поскольку оставшееся пространство будет простаивать. В all-flash vSAN целесообразно использовать под кэш флэш-носители с большей скоростью и временем жизни. Такой подход к организации кэша в all-flash vSAN обусловлен тем, что флэш-capacity-носители и так быстрые, поэтому нет смысла кэшировать чтение. Выделение всей ёмкости кэша на запись, кроме её ускорения, позволяет продлить срок жизни capacity-уровня и снизить общую стоимость системы, поскольку для постоянного хранения можно использовать более дешевые носители, в то время как один более дорогой, производительный и живучий флэш-кэш будет защищать их от лишних операций записи. Обеспечение отказоустойчивости Отказоустойчивость ВМ и соотношение объема полезного и занимаемого в общем пространства хранилища vSAN определяются двумя параметрами политики хранения: • Number of failures to tolerate – количество допустимых отказов, определяет количество хостов кластера отказ которых сможет пережить ВМ. • Failure tolerance method – метод обеспечения отказоустойчивости. vSAN предлагает 2 метода обеспечения отказоустойчивости: • RAID-1 (Mirroring) – полная репликация (зеркалирование) объекта с размещением реплик на разных хостах, аналог сетевого raid-1. Позволяет пережить кластеру до 3-х отказов (хостов, дисков, дисковых групп или сетевых проблем). Если Number of failures to tolerate = 1, то создается 1 реплика (2 экземпляра объекта), пространство, реально занимаемое ВМ или её диском на кластере, в 2 раза больше её полезной ёмкости. Если Number of failures to tolerate = 2, имеем 2 реплики (3 экземпляра), реально занимаемый объем в 3 раза больше полезного. Для Number of failures to tolerate = 3, имеем 3 реплики, занимаем пространство в 4 раза больше полезного. Данный метод отказоустойчивости неэффективно использует пространство, однако предоставляет максимальную производительность. Может использоваться для гибридной и all-flash конфигурации кластера. Минимально необходимое количество хостов 2-3 (для отработки 1 отказа), рекомендуемый минимум – 4 хоста, дает возможность ребилда при отказе. • RAID-5/6 (Erasure Coding) – при размещении объектов производится вычисление блоков чётности, аналог сетевого raid-5 или -6. Поддерживается только all-flash конфигурация кластера. Позволяет кластеру отработать 1 (аналог raid-5) или 2 отказа (аналог raid-6). Минимальное количество хостов для отработки 1 отказа равно 4, для отработки 2-х отказов равно 6, рекомендуемые минимумы 5 и 7, соответственно, для возможности ребилда. Данный метод позволяет достичь значительной экономии пространства кластера по сравнению с RAID-1, однако приводит к потере производительности, которая может оказаться вполне приемлемой для многих задач, учитывая скорость all-flash. Так, в случае 4-х хостов и допуске 1 отказа полезное пространство, занимаемое объектом при использовании Erasure Coding, будет составлять 75% от его полного объема (для RAID-1 имеем 50% полезного пространства). В случае 6-ти хостов и допуске 2-х отказов полезное пространство, занимаемое объектом при использовании Erasure Coding, будет составлять 67% от его полного объема (для RAID-1 имеем 33% полезного пространства). Таким образом, RAID-5/6 в данных примерах оказывается эффективнее RAID-1 по использованию ёмкости кластера в 1,5 и 2 раза, соответственно. Ниже представлено распределение данных на уровне компонент кластера vSAN при использовании RAID-5 и RAID-6. Cn – компоненты объекта, Dn – блоки данных, Pn и Qn – блоки четности. vSAN позволяет по-разному обеспечивать отказоустойчивость для различных ВМ или их дисков. В рамках одного хранилища можно для критичных к производительности ВМ привязать политику с зеркалированием, а для менее критичных ВМ настроить Erasure Coding для экономии пространства. Таким образом, будет соблюдаться баланс между производительностью и эффективным использованием ёмкости. Ниже приводится таблица с минимальным и рекомендуемым количеством хостов или доменов отказа для различных вариантов FTM/FTT: Домены отказа vSAN вводит понятие доменов отказа (fault domain) для защиты кластера от отказов на уровне серверных стоек или корзин, которые логически группируются в эти домены. Включение этого механизма приводит к распределению данных для обеспечения их отказоустойчивости не на уровне отдельных узлов, а на уровне доменов, что позволит пережить отказ целого домена – всех сгруппированных в нем узлов (например, серверной стойки), поскольку реплики объектов будут обязательно размещаться на узлах из разных доменов отказа. Количество доменов отказа вычисляется по формуле: number of fault domains = 2 * number of failures to tolerate + 1. vSAN минимально требует 2 домена отказа, в каждом по 1 или несколько хостов, однако рекомендуемое количество равно 4, поскольку допускает возможность ребилда в случае отказа (2-3 домена не дают возможность ребилда, некуда). Таким образом, метод подсчета числа доменов отказа аналогичен, методу подсчета количества хостов для отработки нужного числа отказов. В идеале в каждом домене отказа, должно быть одинаковое количество хостов, хосты должны иметь идентичную конфигурацию, пространство одного домена рекомендуется оставлять пустым для возможности ребилда (например, 4 домена с отработкой 1 отказа). Механизм доменов отказа работает не только при Зеркалировании (RAID-1), но и для Erasure Coding, в этом случае каждый компонент объекта должен размещаться в разных доменах отказа и формула расчета числа доменов отказа меняется: минимум 4 домена для RAID-5 и 6 доменов для RAID-6 (аналогично расчету числа хостов для Erasure Coding). Дедупликация и сжатие Механизмы дедупликации и сжатия (ДиС) поддерживаются только в all-flash конфигурации и могут быть включены только на кластер vSAN в целом, выборочное включение для отдельных ВМ или дисков с помощью политик не поддерживается. Использовать только одну из этих технологий тоже не получится, только обе сразу. Включении ДиС заставляет объекты автоматически страйпиться на все диски в дисковой группе, это позволяет избежать ребалансировки компонентов и выявлять совпадения блоков данных из разных компонент на каждом диске в дисковой группе. При этом сохраняется возможность задать старайпинг объектов вручную на уровне политик хранения, в т.ч. за пределы дисковой группы. При включении ДиС нецелесообразно на уровне политики резервировать пространство под объекты (параметр Object Space Reservation, толстые диски), поскольку это не даст прироста производительности и отрицательно скажется на экономии проcтранства. ДиС производится после подтверждения операции записи. Дедупликация производится до выгрузки данных из кэша над одинаковыми блоками 4К внутри каждой дисковой группы, между дисковыми группами дедупликация не производится. После дедупликации и перед выгрузкой данных из кэша производится их компрессия: если реально сжать 4K до 2К или меньше, то компрессия производится, если нет, то блок остается несжатым, чтобы избежать неоправданных накладных расходов. В дедуплицированном и сжатом виде данные находятся только на уровне хранения (capacity), это приблизительно 90% объема данных кластера. При этом накладные расходы на ДиС составляют порядка 5% общей ёмкости кластера (хранение метаданных, хэшей). В кэше данные находятся в обычном состоянии, поскольку запись в кэш осуществляется гораздо чаще, чем в постоянное хранилище, соответственно накладные расходы и деградация производительности от ДиС в кэше были бы значительно больше, чем бонус от оптимизации его относительно малой ёмкости. Следует отметить наличие вопроса выбора между малым числом больших дисковых групп или множеством маленьких. На больших дисковых группах эффекта от ДиС будет больше (он делается внутри групп, а не между ними). У множества мелких дисковых групп кэш работает более эффективно (его пространство возрастает за счет увеличения общего числа кэш-носителей), будет больше доменов отказа, что будет ускорять ребилд при отказе 1 дисковой группы. Пространство, занимаемое цепочками снапшотов, также оптимизируется за счет ДиС. Страйпинг объектов и количество компонент Параметр политики хранения Number of disk stripes per object задает количество отдельных capacity-носителей, по которым будут распределены компоненты одной реплики объекта (диска ВМ). Максимальное значение этого параметра, а значит максимальная длинна страйпа, которую поддерживает vSAN, равно 12, в этом случае реплика объекта распределяется на 12 носителей. Если заданная длина страйпа превышает число носителей дисковой группе, значит реплика объекта будет растянута на несколько дисковых групп (скорее всего внутри 1 хоста). Если заданная длина страйпа превышает число носителей хоста, значит реплика объекта будет растянута на несколько хостов (например, все носители 1 хоста и часть носителей другого). По умолчанию, длина страйпа задается равной 1, это значит, что страйпинг не производится и реплика (при размере до 255ГБ) размещается на 1 носителе в виде 1 компоненты. Теоретически страйпинг может дать прирост производительности за счет распараллеливания в/в, если носители на которые страйпится объект не перегружены. Страйпинг объекта на несколько дисковых групп, позволяет распараллелить нагрузку не только по capacity-носителям, но и утилизировать ресурсы кэш носителей вовлеченных дисковых групп. VMware рекомендует оставлять параметр «число страйпов на объект» равным 1, как задано по умолчанию, и не страйпить объекты, за исключением тех случаев, когда страйпинг допустим, необходим и реально позволит повысить производительность. В общем случае считается, что страйпинг ощутимого прироста производительности дать не сможет. В гибридных конфигурациях эффект от страйпинга может быть положительным, особенно при интенсивном чтении, когда возникают проблемы с попаданием в кэш. Потоковая запись также может быть ускорена за счет страйпинга, в т.ч. в all-flash конфигурации, поскольку могут утилизироваться несколько кэш-носителей и распараллеливается вытеснение данных на постоянные носители. Следует учитывать, что страйпинг приводит к значительному росту количества компонент кластера. Это важно для кластеров с большим количеством ВМ и объектов, когда лимит компонент на кластер (9000) может быть исчерпан. Необходимо учитывать, что максимальный размер 1 компонента объекта равен 255ГБ, это значит, что если объект имеет большой размер, его реплика будет автоматически разбита на число компонентов, кратное 255. В таком случае, независимо от политики страйпинга компоненты реплики будут разнесены по нескольким носителям, если их очень много (больше, чем носителей на хосте или в кластере, например, создаем диск 62ТБ), то на носитель может попасть по несколько компонент одного объекта. Планирование ёмкости кластера vSAN При планировании размера хранилища кластера vSAN необходимо учитывать, что реально занимаемое пространство с учетом используемых методов отказоустойчивости (зеркало или EC) и количества допустимых отказов (от 1 до 3х) может значительно превышать полезную ёмкость кластера. Также необходимо учитывать воздействие методов оптимизации использования пространства (EC и ДиС). Следует учитывать выделение пространства под swap-файлы (размер ОЗУ каждой ВМ) и хранение снапшотов. При заполнении ёмкости vSAN на 80% начинается ребалансировка кластра – это фоновый процесс, перераспределяющий данные по кластеру и вызывающий значительную нагрузку, лучше не допускать его наступления. Порядка 1% пространства уходит при форматировании носителей кластера под файловую систему vSAN (VSAN-FS). Небольшая доля пространства уходит на метаданные ДиС (5%). Поэтому VMware рекомендует проектировать кластер vSAN с запасом ёмкости 30%, для того чтобы не доводить до ребалансировки. Выбор storage-контроллера vSAN рекомендует и поддерживает использование нескольких storage-контроллеров на одном хосте. Это позволяет увеличить производительность, ёмкость и отказоустойчивость на уровне отдельных узлов. При этом ни одна vSAN ready node не содержит более 1 storage-контроллера. Рекомендуется выбирать контроллеры с максимально большой длиной очереди (не менее 256. Рекомендуется использовать контроллеры в режиме pass-through, когда диски напрямую презентуются гипервизору. vSAN поддерживает использование контроллеров в режиме raid-0, однако их применение приводит к дополнительным манипуляциям при сопровождении (например, при замене носителя). Внутренний кэш контроллера рекомендуется отключать, если невозможно, то настроить 100% на чтение; фирменные режимы акселерации контроллеров также необходимо отключать. Отработка отказов В случае отказа capacity-носителя его ребилд может быть произведен внутри той же дисковой группы или на другую группу (на том же хосте или на другом), это зависит от наличия свободного места. Отказ кэш-носителя приводит к ребилду его дисковой группы целиком. Ребилд может быть произведен на тот же хост (если на нем есть еще дисковые группы и свободное место) или на другие хосты. На случай отказа хоста для ребилда лучше предусмотреть как минимум 1 свободный хост, если нужно отработать несколько отказов, то и свободных хостов должно быть несколько. Если компонент (диск или дисковый контроллер) деградировал (отказ компонента без возможности восстановления), то vSAN начинает его ребилдить немедленно. Если компонент (потеря сети, отказ сетевой карты, отключение хоста, отключение диска) отсутствует (временное отключение с возможностью восстановления), то vSAN начинает его ребилдить отложенно (по умолчанию, через 60 мин). Естественно, условием ребилда является наличие свободного места в кластере. После отказа (носителя, дисковой группы, хоста, потери сети) vSAN останавливает в/в на 5-7 секунд пока оценивает доступность потерянного объекта. Если объект находится, то в/в возобновляется. Если через 60 минут после отказа хоста или потери сети (начался ребилд), потерянный хост возвращается в строй (восстановлен или поднята сеть), vSAN сама определяет, что лучше (быстрее) сделать: доделать ребилд или синхронизировать вернувшийся хост. Контрольные суммы По умолчанию политики хранения vSAN осуществляют вычисление контрольных сумм для контроля целостности объектов. Вычисление контрольных сумм производится для каждого файла, их проверка осуществляется как фоновый процесс на операциях чтения/записи и для данных, остающихся холодными в течении года. Данный механизм позволяет выявлять повреждения данных по программным и аппаратным причинам, например, на уровне памяти и дисков. При обнаружении несоответствия контрольной суммы vSAN автоматически восстанавливает поврежденные данные путем их перезаписи. Вычисление контрольных сумм можно отключить на уровне политик хранения. Планирование сети vSAN vSAN поддерживает nic-teaming с агрегированием портов и балансировкой нагрузки. vSAN требует включения мультикаст-трафика в своей сети. Если в одной подсети размещается несколько кластеров vSAN, необходимо назначить их хостам разные мультикаст-адреса, для разделения их трафика. При проектировании сети vSAN рекомендуется закладывать leaf-spine архитектуру. vSAN поддерживает NIOC для выделения гарантированной полосы пропускания под свой трафик. NIOC может быть запущен только на distributed vSwitch, vSAN дает возможность их использования в любой редакции vSphere (они входят в лицензию vSAN). vSAN поддерживает использование Jumbo-фреймов, однако VMware считает прирост производительности от их использования незначительным, поэтому даёт следующие рекомендации: если сеть их уже поддерживает – можно использовать, если нет, то для vSAN они совсем необязательны, можно обойтись без них. Пример размещение объектов в кластере vSAN Выше были описаны состав, структура и принципы размещения объектов и компонентов в кластере vSAN, методы обеспечения отказоустойчивости, использование политик хранения. Теперь рассмотрим, как это работает на простом примере. В нашем распоряжении кластер vSAN из 4-х хостов в all-flash конфигурации. На рисунке ниже условно представлено, как в этом кластере будут размещаться 3 диска ВМ (вДиски). вДиск-1 был привязан к политике хранения с отработкой 1 отказа (Failure To Tolerate (FTT) = 1) и использованием Erasure Coding (Fault Tolerance Method (FTM) = EC). Таким образом, объект вДиск-1 был распределен в системе в виде 4 компонент, по 1 на хост. Данные (data) вДиска внутри этих компонент записаны вместе с вычисленными значениями четностей (parity), фактически это сетевой RAID-5. вДиск-2 и вДиск-3 были привязаны к политикам хранения с отработкой 1 отказа (FTT = 1) и зеркалированием (FTM = Mirror). Уточним, что вДиск-2 имеет полезный размер менее 255ГБ и для него задан размер страйпа по умолчанию (Number of disk stripes per object = 1). Поэтом объект вДиск-2 был размещен на кластере в виде 3х компонент на разных узлах: две зеркальные реплики и свидетель (witness). вДиск-3, в данном случае, имеет полезный размер 500ГБ и для него задан размер страйпа по умолчанию. Поскольку 500ГБ больше 255ГБ, vSAN автоматически разбивает одну реплику объекта вДиск-3 на 2 компонента (Компонент1-1 и Компонент1-2) и кладет на Хост-1. Их реплики (Компонент2-1 и Компонент4-2) размещаются на хостах 2 и 4, соответственно. В данном случае свидетель отсутствует, поскольку алгоритм расчета кворума с использованием голосов позволяет без него обойтись. Необходимо отметить, что vSAN разместила вДиск-3 на пространстве кластера именно таким образом автоматически и на свое усмотрение, руками это задать не получится. С тем же успехом она могла разместить эти компоненты на узлах по-другому, например, одну реплику (Компонент1-1 и Компонент1-2) на Хост-4, вторую на Хост-1 (Компонент2-1) и Хост-3 (Компонент4-2). Либо могла выделить под реплики 2 хоста (2 компоненты на Хост-1 и 2 компоненты на Хост-3), а на третий разместить свидетеля (Хост-4), это уже 5 компонент, а не 4. Конечно, автоматическое размещение объектов не является произвольным, vSAN руководствуется своими внутренними алгоритмами и старается равномерно утилизировать пространство и по возможности сократить количество компонент. Размещение вДиск-2 тоже могло быть иным, общее условие – компоненты разных реплик и свидетель (если он есть) должны находиться на разных хостах, это условие отработки отказа. Так, если бы вДиск-2 имел размер чуть меньше 1,9ТБ, то каждая из его реплик состояла бы из 8 компонент (одна компонента не более 255ГБ). Такой объект можно было бы разместить на тех же 3х хостах (8 компонентов 1 реплики на Хосте-1, 8 компонентов 2 реплики на Хосте-2, свидетель на Хосте-3. Либо vSAN мог бы разместить его без свидетеля, распределив 16 компонентов обеих реплик по всем 4 хостам (без пересечения разных реплик на одном хосте) Рекомендации по эффективному использованию пространства Просто привожу таблицу из рекомендаций VMware: Поддержка режима Stretched Cluster vSAN поддерживает работу в режиме Stretched Cluster (растянутый кластер) с охватом 2х географически разнесенных площадок (сайтов), при этом общий пул хранения vSAN также распределяется между сайтами. Оба сайта являются активными, в случае выхода из строя одной из площадок, кластер использует хранилище и вычислительные мощности оставшегося сайта для возобновления работы рухнувших сервисов. Подробное рассмотрение особенностей Stretched Cluster выходит за рамки данной публикации. Полезные ссылки » Документация по vSAN 6.5 на VMware vSphere 6.5 Documentation Center » Руководство по дизайну и масштабированию vSAN 6.2 » Руководство по дизайну сети vSAN 6.2 » Технологии оптимизации ёмкости vSAN 6.2 » Страйпинг в vSAN » Блог VMware по vSAN
Дайджест Университета ИТМО: #2 Научные разработки, видеосюжеты об ученых и ближайшие мероприятия

Вызывает антирес и такой ишо разрез (Царь из «Про Федота-стрельца») Всё в Cache хранится в глобалах. Данные, метаданные, классы, программы. Для просмотра глобалов в Портале управления существует удобный инструмент — страница «Просмотр данных глобала». Её-то мы сегодня и рассмотрим. Примером глобала нам будет служить ^DeepSee.Cubes. Это глобал, в котором хранится список кубов DeepSee. Для чтения этой статьи знать DeepSee вам совершенно не обязательно. Чтобы попасть на страницу «Просмотр данных глобала», откройте Портал Управления, выберите «Обозреватель системы» (System Explorer) > «Глобалы» (Globals). Затем слева нужную область, и нажмите «Просмотр» рядом с нужным глобалом. В нашем случае выберите область SAMPLES и глобал DeepSee.Cubes. На моей инсталляции эта страница выглядит так: В серьёзных глобалах данных очень много (миллионы узлов). По умолчанию страница Просмотра показывает только первые 100. Можно увеличить это число, но чем большее количество узлов для вывода вы зададите, тем дольше страница будет грузиться. Самый интересное поле ввода на этой странице — Маска Поиска глобалов. Рассмотрению различных масок мы и посвятим оставшуюся часть статьи. Итак, пусть маска содержит Имя узла. Просмотр выведет только этот узел. Без потомков, даже если они есть. Если значения в самом узле нет, но есть потомки, Просмотр покажет значение «~pointer». Имя узла без последней закрывающей скобки. Просмотр выведет узел и всех его потомков: Пустые индексы в имени глобала. Просмотр выведет все узлы, которые подходят под маску. В данном примере Просмотр выводит все узлы, у которых три индекса, третий из которых “bucketSize”, а первые два — любые: Можно задать все индексы пустыми. Тогда просмотр выведет все узлы, у которых индексов указанное число. Например три: Два: Или один: Интервалы. Значение индекса можно записать интервалом начало:конец. Просмотр покажет только те узлы, индексы, которых попадают в заданный интервал. Описание масок на английском языке приведено в документации. Надеюсь, использование масок сделает ваше повседневное общение с глобалами ещё приятнее! Бонус Страница Просмотр использует публичный API — запрос Get в классе %Library.Global: SAMPLES>do ##class(%ResultSet).RunQuery("%Global","Get",$namespace,"^DeepSee.Cubes()") Global Name:Value:Name Format:Value Format:Permissions: ^DeepSee.Cubes("classes"):~pointer:1:1:: ^DeepSee.Cubes("cubes"):~pointer:1:1:: ^DeepSee.Cubes("kpis"):~pointer:1:1:: ^DeepSee.Cubes("prior"):~pointer:1:1:: ^DeepSee.Cubes("sharesIndex"):~pointer:1:1::```

Яндекс.Пробки и связанные с ними функции в Навигаторе и Картах работают благодаря данным о скорости машин на разных участках дорог. Это совсем не новая, но по-прежнему эффективная схема. Вопрос, возникший уже по мере развития Пробок — можно ли использовать указанные данные как-нибудь ещё? Аналитик Карт Леонид Медников рассказал о примере такого использования на конференции Яндекса «Пути Сообщения 2016». Под катом — расшифровка доклада и большинство слайдов. Тема моего рассказа – выявление проблемных мест на дороге при помощи данных, которые у нас есть. Вначале расскажу, почему это так важно, и потом мы увидим, насколько просто при помощи Яндекс.Пробок находить проблемные места, которые и создают заторы в городе. Итак, начну с теории. Довольно простой. Вот у нас есть дорога, дороги состоят из полос, по одной полосе в теории не может проехать более 1,5 тыс. автомобилей, около того, за час. Это связано с тем, что они держать дистанцию друг за другом где-то в две секунды. Если мы хотим перевозить больше людей, там либо надо больше людей в один автомобиль помещать, либо все-таки сажать туда автобус, чтобы он ехал. Очень здорово, что общественный транспорт развивается. Но если мы говорим про автомобилистов, то всё, 1,5 тыс. автомобилей и не больше. Проблема только в том, что может быть меньше. С этим хочется что-то делать. Из-за чего может быть меньше автомобилей? Первый самый распространенный случай – просто столько автомобилей нет. Проезжает меньше автомобилей, дороги пустуют. С этим отлично борется Яндекс.Навигатор, если какая-то дорога пустует, он отправит туда всех водителей, чтобы они поскорее ее заняли и объехали существующую пробку. Проблема в том, что как раз существующие пробки – это второй фактор, который снижает пропускную способность дороги. Может, это не очень очевидный факт, заключающийся в том, что если мы собрали пробку, то мы теперь эту дорогу используем менее эффективно. Про это хочу подробнее поговорить на примере графика. По горизонтальной оси мы видим скорость движения в км/ч, по вертикали – количество машин, которое может проехать, если скорость потока такая. Что здесь важно? Здесь есть зона высоких скоростей, где пропускная способность дороги мало меняется. Это важный практический факт. Он говорим о том, что если у нас разрешенная скорость 60 км/ч, мы можем сделать ее 100, 50 или 40 км/ч, пропускная способность дороги сильно не изменится. Это высокие скорости. Но на скоростях где-то ниже 20 км/ч, ситуация прямо противоположна. Здесь каждый км/ч отнимает пропускную способность дороги очень заметно. Если мы с 60 км/ч снизили скорость до 7 км/ч по какой-то причине, то мы потеряли в два раза пропускную способность дороги. То есть построили двухполосную дорогу, а едет как будто однополосная. Продемонстрирую, как это работает. Предположим, есть поток машин определенный. Если у нас скорость выше границы по этому графику, выше 20 км/ч, то спокойно дорога справляется, машины едут. Если по какой-то причине замедлились машины, значит, уже пропускная способность стала ниже той, которая требуется от дороги, и это значит, что машины начинают скапливаться. В данном случае у нас 1200 машин проезжает в час, а выехать может на такой скорости только 1000. Значит, мы собираем 200 машин в час, при длине машины в 5 метров это у нас уже километровая пробка. Почему же снижаются скорости? Что с этим можно делать? Первое – когда весь поток останавливается светофором или лежачим полицейским, разбитой дорогой, по какой-то причине дорога есть, но все движутся медленнее. Вторая причина – сужение дороги из-за конструктивных особенностей, ремонта и так далее. На втором примере хочу чуть подробнее разобраться с поиском проблемных мест. Типичная картинка, здесь она немного гипертрофирована, дорога по какой-то причине сужается. Проблема в том, что пропускная способность всей дороги определяется тем местом, где она самая низкая. Как цепь рвется по самому слабому звену, так и здесь пропускная способность всей дороги определяется одним место. До и после у нас есть пять полос, они бесполезны. У нас реально есть одна полоса. Но самое худшее еще и то, что у нас нет даже этой одной полосы, потому что только что мы выяснили, что если у нас в самом узком месте машины двигаются медленно, то здесь пропускная способность дороги теряется. У нас на вид пятиполосная дорога, по факту – 0,5 полос. Таких ситуаций допускать совсем не хотелось бы. Что с этим можно сделать? Какие есть идеи? Везде сделать одну полосу. Казалось бы, парадокс. Давайте уберем эти полосы, или если это какое-то временное явление, просто обеспечить плавное сужение дороги. Нельзя давать водителям в последний момент перестраиваться, они в этот момент теряют скорость в самом узком месте, это недопустимо. Нужно дать возможность достаточного расстояния, чтобы машины перестроились и не теряя скорости проехали узкое место. Казалось бы, простая теория, но я покажу пару примеров, как это используется или не используется. Это, слава богу, исторический снимок в Москве, но он имел место быть. Съезд с внешней стороны МКАД на Ленинградское шоссе в сторону области. Думаю, многие там стояли. Рам сейчас реконструируют, все-таки уже не совсем всё так. Что здесь важно, что мы особенно остров видим? Здесь создана ситуация, когда машины вынуждены снижать скорость. Потому что три полосы врезаются в основной поток, невозможно это сделать неаварийно, если ты не один глубокой ночью, то есть ты вынужден снижать скорость, другие машины снижают скорость, дорога потом сужается, и мы в самом узком месте получаем снижение скорости, и без того в сложной ситуации мы получаем еще снижение пропускной способности. Второй пример, тоже реальный снимок из того же космоса. Та же ситуация: основная дорога даже более узкая, на съезде у нас не три полосы, а две, но что сделано? Когда происходит слияние, машины, в принципе, друг друга не чувствуют, две полосы параллельно встали. Одни другой не мешают. И дальше у них есть полкилометра на то, пока у них отнимут одну полосу, и еще полкилометра, пока отнимут вторую полосу. Как раз на скорости у них есть возможность перестроиться. Конечно, можно и на такую развязку подать такой поток машин, что она не справится, потому что полос становится меньше, но до определенного предела мы здесь не получим пробку и позволим полной пропускной способности дороги работать. Хочу подвести итог первой части. На дорогах существуют так называемые бутылочные горлышки, узкие места, которые и определяют пропускную способность дороги, они создают пробки, и если мы хотим что-то с этим делать – два вывода. Надо лечить здесь и не надо лечить больше нигде. Потому что если мы вспомним пятиполосную магистраль, можно ее в любом другом месте расширить до 10 полос, сузить до двух, пригласить ремонтников – никакой проблемы, ничего не поменяется. Но вот это одно единственное узкое место задает параметры всей трассы. Мой дальнейший рассказ будет посвящен выяснению того, где же эти места. И не всегда решение проблемы дорогостоящее, не всегда надо строить лишнюю развязку. Иногда надо отнять лишнюю полосу, или если там стоит светофор – может, перенастроить его навсегда или в зависимости от времени дня. Решения необязательно какие-то суперсложные и дорогостоящие. Как же мы находим эти узкие места? Достаточно просто. Этих данных у Яндекс.Пробок нет, сколько там полос, что и как, но мы можем видеть скорость движения, а она имеет совершенно понятный паттерн: сначала машины едут медленно, потом быстро. И видя такую картинку, особенно если пробка крупная, мы можем сказать, что в этом месте есть какая-то проблема. Какая? Надо идти на место и изучать. Давайте посмотрим, как можно находить на реальных примерах, где же у нас узкие места. Это Шоссе Энтузиастов, одна из лучших трасс для иллюстрации пробок в Москве. Здесь типичные ежедневные пробки, в начале этой пробки мы должны смотреть, что здесь происходит. Важный практический нюанс: мы видим, что красное переходит в желтое, а потом в зеленое. Скорее всего, проблема где-то на границе желтого и зеленого. Если у нас есть два узких места, если мы упираемся во второе, то бесполезно расширять первое. Мы расширим первое, и сразу же вся пробка перенесется дальше, в данном случае на 100 метров, поэтому надо смотреть второе узкое место, там стоит светофор, ну и в целом, например, если мы хотим решить проблему пробок, и знаем, что где-то неровная дорога, в первую очередь ее надо здесь выравнивать. Если мы хотим перенастроить светофор, надо в первую очередь посмотреть здесь. Если хотим посмотреть, что там с ограждениями, в первую очередь надо смотреть здесь, в узком месте. Аналогичная ситуация в обратную сторону. Пробка, легко определяем узкое место, все то же самое. Не только на эти вопросы можно ответить благодаря поиску узких мест. В некоторых случаях можно даже ответить на вопрос, стоит ли строить дорогу или нет. Это можно делать не всегда, но иногда можно. Вот пример из Новосибирска. Здесь предлагалось построить новую дорогу. Случай интересен тем, что она проходит параллельно существующей, поэтому получается достаточно простая аналитика. Посмотрим пробки в утренний и вечерний час-пик, где у нас узкие места. Типичная картина пробок в утренний час-пик. Здесь есть затруднение, которое упирается в этот перекресток. Все едут влево – вниз, на юге центр города, с утра. Возможно, надо дать больше приоритета тем, кто едет на юг на этом перекрестке в утренний час-пик. Вторая проблема здесь – интересный пример, заключающийся в том, что дальше идет сплошная желтая линия почти чуть ли не до самого центра, и это значит, что уже всё, здесь проблема может быть нерешаемой. Когда все упираются в центр, здесь уже не расширишь, здесь опять слава общественному транспорту, потому что когда все пробки упираются в центр, таким способом проблему не решить. Дорога здесь не причем, она никак не расширяет узкое место, значит, никак не ситуацию с пробками не повлияет. Может быть, людям будет удобнее ездить, быстрее, все что угодно, в смысле комфортнее проезжать этот участок, но пробки она не изменит. Картинка в вечерний час-пик, то же самое, узкие места, возможно, надо дать больший приоритет людям, поворачивающим на север из центра. Здесь какая-то проблема, тут можно дать приоритет тем, кто едет на север, но новая дорога проблему пробок не решит. Простой анализ можно сделать на сервисе за пять минут. Говоря про сервис, в заключение хочу напомнить: посмотреть типичную карту пробок может любой человек, энтузиаст или мэр, достаточно зайти на Яндекс.Карты, включить Пробки, есть секретная кнопка с часиками, она является машиной времени, вы переключаетесь на статистику пробок, выбираете любой день недели, любое время. Обычно это будни – 8:30 утра, утренний пик, и где-то 18:30 – вечерний пик. И смотрим на пробки. Вот здесь в Нижнем Новгороде можно выделить какие-то основные места на выезде в пятницу из города, где реально решать проблему и помогать автомобилистам легче выезжать. Последний практический трюк на примере узкого места: Те, кто выезжают из центра, на самом деле проходят ряд пробок. Бесполезно решать проблему в первой пробке, мы просто всех автомобилистов отправим удлинять вторую. Либо надо решать все, либо если по одной, то надо решать с последней, как здесь и выделено, потому что дальше уже автомобилисты поедут свободно, но в первых трех они постоят. Как вариант, можно сказать, что мы проблему не решаем, она такая, здесь слишком много пока сложностей. Но решать только первую и ожидать, что мы что-то улучшим, к сожалению, не приходится. Все это можно сделать самостоятельно, но если вы готовы влиять на ситуацию и изучать подробнее, то мы в этом готовы вам помочь. Можно через меня спросить. Мы можем не только глазами, но и автоматом находить узкие места, предоставлять такие данные. Если вы готовы менять ситуацию, мы готовы посчитать уже по этим узким местам время проезда в течение дня, дней недели, и когда будут внесены какие-то изменения, это может быть изменение режима работы светофора, посмотреть, что стало. Для тех, кто совсем серьезно хочет погружаться в аналитику, невозможно на все вопросы ответить только изучением узких мест. Есть Yandex Data Factory, это отдельное подразделение Яндекса, которое как раз занимается платной аналитикой, к ним уже на коммерческой основе можно приходить за более глубоким анализом, за автоматическими отчетами и тому подобным. На этом у меня всё.

Уязвимости в iOS — это определенно главная новость недели. Вчера компания Apple выпустила срочный апдейт для своих мобильных устройств, и в этот раз, пожалуй, действительно надо быстрее обновиться. Уязвимость была обнаружена лабораторией Citizen Lab в Университете Торонто и компанией Lookout. На сайте Citizen Lab опубликован подробный отчет, и пожалуй именно он делает событие особенно важным, так как дает важный контекст о том, как дыра эксплуатировалась до обнаружения. Это не так уж часто происходит. Уязвимости CVE-2016-4655 и 4656 затрагивают ядро iOS: если первая может обеспечить утечку данных, то эксплуатация второй приводит к выполнению произвольного кода. Еще одна уязвимость (CVE-2016-4657, хотя в отчете Lookout порядок нумерации другой) обнаружена в компоненте WebKit и также приводит к выполнению произвольного кода при посещении зараженного вебсайта. Все три уязвимости используются комплексно: сначала заражение через веб-сайт, потом джейлбрейк устройства, причем с использованием публично доступных джейлбрейк-компонентов (Cydia). Расследование, закончившееся обнаружением уязвимостей, началось с подозрительных SMS со ссылками, которые гражданский активист Ахмед Мансур переслал в Citizen Lab. По клику на ссылку на телефон скрытно устанавливался шпионский модуль, который блокировал обновления устройства, и собирал данные из популярных мессенджеров, программ для общения в соцсетях и так далее. По мнению представителя Lookout, эта дыра могла использоваться начиная с 2013 года и версии iOS 7. Кроме того, в истории есть и политический подтекст: в Citizen Lab утверждают, что данный образец кибероружия был разработан одной из компаний, специализирующейся на продаже подобных систем государственным и правоохранительным органам. Впрочем с выпуском патчей информация об эксплойтах и методах атаки может начать использоваться более широко, посему повторюсь — стоит обновиться прямо сейчас. Ждем новый аукцион на Zero-day в iOS. Новый банковский троян использует Powershell в процессе заражения Новость. Исследование «Лаборатории». Новость из Бразилии, где не только Олимпиада, но и сомнительная привилегия страны номер один по количеству финансовых кибератак. Эксперт «Лаборатории» Фабио Ассолини опубликовал короткое исследование интересного банковского трояна Trojan-Proxy.PowerShell.Agent.a. В процессе заражения троян использует командную оболочку Powershell. Рассылается в фишинговых сообщениях, к которым приложен файл в формате .PIF — это такой древний и полузабытый рудимент времен MS-DOS, изначально использовавшийся для сохранения информации о параметрах запуска программ. По какой-то непонятной причине он по-прежнему обрабатывается в Windows, и, по аналогии с .bat-файлами, система выполняет скрипты, в нем содержащиеся. В результате запускается оболочка Powershell, в которой скрипт пытается поменять глобальные настройки прокси-сервера. Собственно это вся «локальная» деятельность трояна, но ее и достаточно: после подмены прокси появляется возможность подсунуть жертве поддельный банковский веб-сайт, очень похожий на настоящий. Не самая совершенная атака за всю историю наблюдений, но она поднимает важную проблему скрытых возможностей инструментов администрирования. А еще больше проблем в будущем может принести даже не PowerShell, а BASH, теперь доступный в Win10 вместе с Linux-подсистемой. Исследователи предупреждают о потенциальной ненадежности алгоритмов шифрования 3DES и Blowfish Новость. Анонс исследования. Алгоритмы шифрования 3DES и Blowfish присоединились к RC4, уже давно находящемуся в списке потенциально ненадежных. В отличие от RC4, эти два алгоритма по-прежнему используется. Blowfish — метод по умолчанию для OpenVPN, а 3DES поддерживается всеми браузерами для коммуникаций по защищенному протоколу HTTPS. Доля подключений 3DES невелика — всего 1-2 процента, но в абсолютных числах это очень много и пользователей, и трафика. О технических деталях исследования говорить пока рано — научная работа только планируется к опубликованию. Тем не менее ее авторы, исследователи из французского института INRIA, утверждают, что им удается расшифровывать зашифрованный трафик с высокой степенью надежности. Причина, если все предельно упростить, в недостатках обоих алгоритмов, которые начинают выявляться при больших объемах переданных данных — от 32 гигабайт. Собственно, это и делает работу исследователей теоретической, тем более что практические параметры проведения атаки еще сложнее. Для моделирования ситуации кражи куки, авторам работы понадобилось два дня и захват 785 гигабайт трафика! Впрочем, если все подтвердится, такие условия ни в коем случае не умаляют заслуги исследователей. Раннее предупреждение о ненадежности алгоритмов шифрования позволяет разработчикам софта и железа отказаться от их поддержки до того, как атака станет практической. Хороший пример — алгоритм хеширования SHA-1. В прошлом году было показано, что атака на него занимает всего (или целых, смотря как смотреть) 49 дней. Хотя это не самая практичная атака, от поддержки SHA-1 с тех пор отказались производители всех основных браузеров. Что еще произошло: Интересное исследование безопасности китайского роутера, в котором забыли создать пароль для рута. В России (и не только) наблюдается заметная нехватка специалистов по информационной безопасности. EFF раскритиковал Microsoft за бульдозерную тактику продвижения Windows 10 (и за телеметрию тоже). Древности: Семейство «Taiwan» Семейство нерезидентных очень опасных вирусов. Обходят подкаталоги и записываются в начало .COM-файлов. При заражении файлов блокируют клавиатуру (видимо, действие направленное против резидентных антивирусных мониторов). Если ни один .COM-файл не найден, то вирусы «Taiwan» могут стереть часть секторов текущего диска и после этого сообщают: «Greetings from National Central University! Is today sunny?». Помимо этой содержат строку "*.com". Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 47. Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
[Перевод] FizzBuzz на TensorFlow

Это продожение статьи Пишем микросервис на KoaJS 2 в стиле ES2017. Часть I: Такая разная ассинхронность. Постараюсь угодить начинающему разработчику, который хочет расстаться с express, но не знает как. Кода будет много, текста мало — я ленивый но отзывчивый. Koa минималистичен, в сам фреймворк не входит даже роутер. Сейчас быстренько его доукомплектуем такими модулями, которые от программиста требуют минимального напряжения. Постановка задачи Банальный пример: Есть таблица товаров (products) на MySQL. Наша задача — дать возможность добавлять/удалять/изменять товары в этой таблице через REST-сервис, который нам предстоит написать. Начнем Создадим 2 папки ./config и ./app. В корневой папке сервиса будет только один файл, который подключает babel и наше приложение из папки ./app require('babel-core/register'); const app = require('./app'); Настройки для babel вынесены в .babelrc Основной файл нашего приложения будет выглядеть так: import Koa from 'koa'; import config from 'config'; import err from './middleware/error'; import routes from './middleware/routes'; const app = new Koa(); app.use(err); app.use(routes.routes()); app.use(routes.allowedMethods()); app.listen(config.server.port, function () { console.log('%s listening at port %d', config.app.name, config.server.port); }); Для хранения конфигурационных настроек я рекомендую модуль config. Он позволяет удобно организовать конфигурацию, вплоть до отдельного инстанса. Наши кастомные middleware будем создавать в папке ./middleware. Для того, чтоб информацию про ошибки отдавать в JSON-формате, напишем ./middleware/error.js export default async (ctx, next) => { try { await next(); } catch (err) ; } } Роуты можно было поместить в основной файл, но тогда код будет казаться сложнее. Костяк сервиса готов. Пишем роуты Для роутов есть много модулей, в том числе с поддержкой koa 2, я предпочитаю koa-router, сильные стороны этого модуля рассмотрим на нашем примере: import Router from 'koa-router'; import product from '../models/product'; import convert from 'koa-convert'; import KoaBody from 'koa-body'; const router = new Router(), koaBody = convert(KoaBody()); router .get('/product', async (ctx, next) => { ctx.body = await product.getAll() }) .get('/product/:id', async (ctx, next) => { let result = await product.get(ctx.params.id); if (result) { ctx.body = result } else { ctx.status = 204 } }) .post('/product', koaBody, async (ctx, next) => { ctx.status = 201; ctx.body = await product.create(ctx.request.body) }) .put('/product/:id', koaBody, async (ctx, next) => { ctx.status = 204; await product.update(ctx.params.id, ctx.request.body); }) .delete('/product/:id', async (ctx, next) => { ctx.status = 204; await product.delete(ctx.params.id); }); export default router; Мы подключаем модель product, о которой поговорим чуть ниже, а также модуль koa-body, который парсит тело post-запроса в объект. С помощью koa-convert мы сконвертируем koa-body в middleware для koa 2. В самом простом случае, роут выглядит предсказуемо: .get('/product', async (ctx, next) => { ctx.body = await product.getAll() }) В случае get-запроса по адресу /product, получаем из модели все записи и передаем их ctx.body для передачи в JSON клиенту. Все необходимые заголовки koa установит сам. А вот POST-запрос обрабатывается интреснее — в роут, начиная со второго аргумента, можно добавлять неограниченное количество middleware. В нашем случае это дает нам возможность подключать koa-body для получения тела запроса, перед тем, как эти данные будут обработаны следующим middleware. По роутам все, если у вас возникли еще вопросы, задавайте их в комментах. Какие ошибки и при каких случаях возвращает REST нигде не описано однозначно, «можно так, можно эдак». Я закодил так, как удобно было бы мне, поэтому если у Вас есть к этой части замечания, то я с удовольсвием их рассмотрю. Создаем модель «product» В качестве БД я выбрал MySQL, просто потому, что она была у меня «под руками». import query from 'mysql-query-promise'; import config from 'config'; const tableName = config.product.tableName; const crud = { getAll: async () => { return query(`SELECT * from ${tableName}`); }, get: async (id) => { let products = await query(`SELECT * FROM ${tableName} WHERE UAH' }) { let product = {name: String(name), price: Number(price), currency: String(currency)}; if (id > 0) product.id = Number(id); let result = await query(`INSERT INTO ${tableName} SET ? ON DUPLICATE KEY UPDATE ?`,[product,product]); if (result.insertId) id = result.insertId; return crud.get(id); }, update: async (id, object') { let uProduct = {}; if (product.hasOwnProperty('name')) uProduct.name = String(product.name); if (product.hasOwnProperty('price')) uProduct.price = Number(product.price); if (product.hasOwnProperty('currency')) uProduct.currency = String(product.currency); let result = await query(`UPDATE ${tableName} SET ? WHERE > Модуль mysql-query-promise написан в нашей компании, я не могу сказать, что это шедевр инжененерной мисли, так как он жестко привязан к модулю config. Но в нашем случае он применим. Простые методы get, delete, put нет смысла коментировать, там код говорит сам за себя, а вот про POST немного раскажу. Я не использовал стрелочную фунуцию, т.к. применил расширенные возможности по передаче параметров из стандарта ES6/ES2015. Таким способом, как в примере мы можем организовать передачу параметров, не заботясь о порядке их следования, кроме того, можно установить «значения по умолчанию» для незаданных пераметров. Тестируем Все, наш сервис готов, можно его запустить и потестировать с коммандной строки: curl -XPOST "127.0.0.1:3001/product" -d '{"id":1,"name":"Test","price":1}' -H 'Content-Type: application/json' curl -XGET "127.0.0.1:3001/product" curl -XPUT "127.0.0.1:3001/product/1" -d '{"name":"Test1"}' -H 'Content-Type: application/json' curl -XGET "127.0.0.1:3001/product/1" curl -XDELETE "127.0.0.1:3001/product/1" Все работает, буду рад вашим предложениям, которые помогут сделать код еще более простым и понятным. Вместо заключения Я понимаю, что мало кто из почитателей express, restify и др. устоявшихся фреймворков готов все бросить и кодить на фреймворке, у которого ядро почитателей только формируется, и который достаточно радикально меняется от версии к версии. К koa написано пока немного middleware и практически нет документации на русском. Но несмотря на это я свой выбор сделал еще 2 года назад, когда узнал о Koa из случайного коментария на хабре. В комментах к первой части статьи пользователь fawer написал о том, что async/await уже доступен в chrome 52 без babel. Будущее уже близко, не пропустите его! Полезные ссылки Примеры для 1-й и 2-й части статьи на gitHub. (не забудьте про «npm install» после клонирования) Список middleware для Koa Пишем микросервис на KoaJS 2 в стиле ES2017. Часть I: Такая разная асинхронность Повышаем отказоустойчивость системы на nodejs

Источник изображения На днях Владимир Скляр (@Vladimir_Sklyar) опубликовал два материала об академическом сегменте интернета: раз и два. Начал писать комментарий… и увлекся. В итоге пишу очень развернутый комментарий. Во-первых, хочу поблагодарить Владимира за любопытные материалы и поднятую тему. Мне, делающему первые шаги в академическом мире, она очень интересна и кажется важной (хотя и понимаю, что для всего хабра эта тема не самая значимая). Несмотря на радость от прочтения материала, замечательный стиль и емкие обобщения (мне очень понравился раздел "В чем причина такого невнимания к этой важной составляющей научной работы?"), осталось ощущение колоссальной недораскрытости темы. На мой взгляд, Владимир затронул лишь самую верхушку айсберга. Дальнейший комментарий разделю на дополнения и уточнения. Дополнения Research Gate пользуется очень неоднозначной славой в академическом сообществе. В основном они достигли этого политикой очень агрессивного навязывания себя миру (для примера). Помимо Research Gate есть более "академичная" Academia.edu. Но не будем вдаваться в холивар. Просто вариантов гораздо больше, чем RG. По моему поверхностному суждению, рейтинг на RG очень часто вводит в заблуждение, не говоря уже о системе endorsement. Q&A на RG — в массе своей собрание вопросов, которые и многие студенты постесняются задать (к словам автора во второй статье "Есть функции размещения профессиональных вопросов участников сети и ответов на них."). Помимо RG и Academia есть уйма вариантов разместить полные тексты своих статей в хороших хранилищах. Для начала супер известный ArXiv. Он появился еще в начале 1990-х и сразу задал уровень, на который до сих пор ориентируются многие подражатели. Для многих загвоздка в том, что этот портал довольно узко специализируется на технических науках. Из заметных современников, наверное, надо отметить молниеносно взлетевший Bioarxiv и очень "всеядный" Figshare. Общее у всех этих архивов — политика невозможности удаления файлов. То есть надо подумать, готов ли драфт к показу, прежде чем засорять веб. Более узкие системы для социальных наук — RePEc и SSRN. Обе весьма уважаемы, но, по-моему, застряли в прошлом немного. О чем еще обязательно надо упомянуть? Политика издательств и журналов касательно опубликования препринтов и постпринтов. Вариантов бесчисленное множество. К счастью, есть проект, который в удобной форме агрегирует всю эту информацию — RoMEO. Ну и, разумеется, при подобном обзоре нельзя обойти вниманием тему персональных сайтов. Должна быть "собственная гавань", где наличие и формат информации зависит только от тебя. Сегодня сделать собственную страничку технически под силу абсолютно любому пользователю. Тут вариантов множество. Для примера, мой сайт. Или вот сайт довольно пожилого исследователя, тоже на базе Google Sites, очень простой, но все главное на месте. А уж образцов прекрасных сайтов на более современных платформах множество. Несколько примеров: сайт на базе WordPress; еще один; а вот прекрасный сайт, созданный с помощью github pages и jekyll. Тут нет пределов совершенству. Я планирую в обозримом будущем освоить создание статического сайта на github pages с помощью R. Вообще, github — это отдельный мир и отдельная тема для обсуждения. Не только программисты, но и многие исследователи могут с его помощью систематизировать, красиво преподнести и сделать воспроизводимыми (!) свои проекты. Кстати, нельзя не заметить прекрасную отечественную разработку — МГУшная ИСТИНА. Она открыта всем исследователям, не только из МГУ. Минимализм и куча прекрасно реализованных вещей. Для авторов, публикующихся не только на английском очень позеленелая система. Ну и, наверное, надо отметить, что "не хиршем единым". Есть любопытный проект Altmetric, который измеряет эффект от статьи в медиасфере (кстати, все большее число издателей интегрируют эти метрики на свои сайты, например, T&F и Wileys). Уточнения К сожалению, национальные журналы русскоязычного сегмента не стремятся к вхождению в Web of Science, Scopus или даже в Google Scholar. Нет никакого процесса попадания в Google Scholar. GS индексирует вообще все, что найдет в формате PDF. Также во второй статье, в разделе про GS, автор пишет расхваливает сервис и, в частности, пишет "Очевидно, что на сегодняшний момент этот сервис развивается". На мой взгляд, это далеко от правды. Если бы гугл вложил в Scholar хоть 10% от усилий, потраченных на мертворожденный Google+, можно было бы действительно сделать так, чтобы все прочие сервисы (равно как и подобные дискуссии и обзоры) отпали за ненадобностью. На сегодняшний день, GS индексирует кучу мусора и не делает никаких различий в качестве материала или хотя бы надежности источника. Web of Science и Scopus хотя бы стараются сортировать шлак. Получается не всегда, но, в целом, шанс встретить у них проиндексированный шлак не велик, особенно если ориентироваться на топовые журналы, замеренные по их же метрикам, например SJR. Порой GS позволяет довольно внушительно выглядеть откровенным академическим фрикам. Например, я натыкался на кадра, у которого более 1000 цитирований в GS и при этом лишь 8 (восемь!) в Scopus. Вот так выглядит типичный список цитирований его статьи на GS. По моему, комментарии излишни. Кроме того, сама фраза (цитата выше), мне кажется, чудовищно далека от действительности. Наши журналы скребутся в Web of Science и Scopus всеми силами. Мало у кого получается. И даже не всегда доползают лучшие. Но это отдельный разговор. Тут нельзя не отметить Russian Science Citation Index от Web of Science. Thomson Reuters решили отобрать 1000 лучших Российских журналов и включить их не в Core Collection, а в отдельную базу. В итоге отобрали около 650. Ну минуточку: в списке ВАК более 2000 наименований. Это к вопросу о релевантности ВАКа как мерила качества журналов. Еще немного про Google Scholar. Во второй статье, описывая функционал GS, Владимир пишет "«Оповещения», на мой взгляд, не столь важны". Резко не согласен. На мой взгляд, это наиболее адекватная из существующих в интернете опций, позволяющая следить за публикациями конкретных авторов. Незаменимо. Также во второй статье про GS "… и некоторую вероятность подключения в скором времени русскоязычного сегмента". Русскоязычный сегмент давно и прекрасно существует. Посмотрите, например, этот профиль. Моих публикаций в Web of Science получилось меньше, чем в Scopus, хотя, собственно говоря, это вопрос стратегии продвижения. Это как раз совсем не удивляет, поскольку Scopus индексирует существенно шире, у WoS критерии жестче. Как правило, все, что есть в WoS, есть и в Scopus. Но не наоборот. ORCID. Отмечено в самом конце второй статьи как планы на будущее. Это совершенный must современного академического мира. Некоторые журналы, а также, например, Bioarxiv, настоятельно рекомендуют всем авторам обзавестить идентификационным номером при первой же возможности. В качестве бонуса Я очень надеюсь, что взлетит проект MIT PubPub. Это потенциальная революция в мире академических публикаций. Одна только система открытого рецензирования чего стоит! Забавно, что после прочтения взрывной статьи про sci-hub и еще одной о последствиях распространения системы, я задумывался о том, как надо реформировать систему публикации академических работ. Так вот, PubPub — это все мои мечтания, только круче. Ну действительно, почему peer-review, институт, на котором держится наука в современном ее виде, — самая неблагодарная и мало вознаграждаемая часть академической работы? Верю в PubPub! P.S. Дискуссия Библиометрия важна, и без нее теперь никуда. В целом, это, наверное, все же хорошо. Но чрезмерный фокус на количественных параметрах тоже уводит от истины. В России (сужу по НИУ ВШЭ) наблюдается типичный для развивающихся стран рейтинговый бум (то же было и в Южной Корее, и в Китае). Учитывая многочисленные несовершенства существующих систем и институтов, стоит воздерживаться от радикальных суждений, основанных на библиометрии. В частности, пассаж из первой статьи ("Я, например, на одной из конференций встретился с человеком, у которого h-index в Scopus равен аж 50. 50 публикаций, каждую из которых процитировали не менее 50 раз, ничего себе!") мне кажется иллюстрацией подобного потенциально опасного количественного подхода. Далеко не все действительно великие исследователи вообще продуцировали за свою жизнь 50 значимых текстов. И далеко не все авторы научных статей вносят заметный вклад в их написание (тут забавная ссылка). Так что надо с осторожностью. Приведу пример потенциального заблуждения, в которое может ввести библиометрическая лихорадка (разумеется, из своей области, демографии). Если строго следовать логике библиометрии, то среди отечественных демографов невозможно не обратить внимание на Коротаева А.В. Меж тем он и его последователи — типичные "надуватели библиометрических пузырей", вклад в науку которых стремится… ну вы поняли. В том, что это так, можно убедиться в коротенькой статье замечательного отечественного демографа Евгения Андреева. Так что не все, что всплывает на поверхность, стоит пристального изучения. И уж совсем в заключение. От души рекомендую всем почитать обращение к научному сообществу библиометристов и Лейденского университета (они, кстати, считаются лучшими в мире). Эксперты призывают не зацикливаться на цифрах!
Специалисты Emsisoft обнаружили еще один вымогатель на JavaScript

Изображение сайта tricentis.com Существующие реалии буквально требуют от разработки программного обеспечения еще больше сокращать время выполнения проекта: от возникновения идеи до выпуска готового продукта. С завидной периодичностью заказчики просят реализовать проект «вчера», чтобы его не скопировал «сегодня» кто-то другой. И, конечно же, бюджет на то, чтобы сделать невозможное, как всегда, ограничен. Разработчикам ничего не остается, как вновь и вновь заниматься оптимизацией техпроцесса, экспериментировать, пробовать новые методологии. В особо «запущенных» случаях временные резервы ищут буквально в каждом отделе, а не только заставляют разработчиков печатать быстрее. Оказывается, быстрее могут работать и тестировщики, и менеджеры, и аналитики, и отдел внедрения. Остается всего ничего – придумать, как этого добиться. На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему. Изображение сайта quora.com Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности. Agile стал достоянием широкой общественности в 2001 году. Гибкая разработка сводится к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Подразумевается, что «гибкий» программный проект готов к выпуску в конце каждой итерации. Однако на практике это происходит далеко не всегда и не так быстро, как теперь хочется клиентам. Кроме того, разработка замедляется из-за того, что у различных подразделений, участвующих в создании программного обеспечения, нет общих инструментов и отсутствует возможность делиться полученными знаниями. Каждое из подразделений выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры. Выяснилось также, что отдел эксплуатации – это еще одно слабое звено, которое остается «за рамками» модели Agile. В 2009 создатели DevOps вселили в широкую общественность надежду на светлое будущее. Вот так формулируются благородные цели DevOps: DevOps (development и operations) — методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения, и нацелена на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и сервисы. Стоит отметить, что Agile – не является непременным условием для реализации DevOps. Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом». В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, описаны лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути»: Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела. В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT. Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью практически любой инициативы по совершенствованию процесса является сокращение и усиление обратной связь, чтобы необходимые поправки могли внедряться постоянно. Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству. По словам многих заказчиков, ценность описанного подхода состоит в том, что он позволяет получить полную картину модели разработки — с участием абсолютно всех заинтересованных сторон, с четко обозначенными процессами и интеграционными механизмами. Мы попросили экспертов ответить на несколько вопросов, чтобы узнать, как обстоят дела с DevOps в русскоговорящем мире. Евгений Оглоблин, DevOps компании из крупнейшей российской тройки: 1. Каким компаниям подходит DevOps? Мне кажется, что в достаточной степени любым. Крупным – потому что это позволит ускорить разработку, тестирование и релизы продуктов, маленьким – потому что все будут вовлечены в процесс, появится некоторое подобие взаимозаменяемости сотрудников. 2. Насколько глубоко понимание DevOps в русскоговорящем сообществе? У нас еще очень много «классических админов», которым про продукт вообще не интересно. У них FreeBSD 8 или CentOS 5, все работает и кушать не просит. Значит, и изобретать ничего не нужно. Плюс сопутствующая DevOps'у автоматизация подразумевает достаточно много работы, зачастую — с новыми технологиями, иногда вообще не известными людям. Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог — в любой компании есть свои тонкости, наследие и тому подобное. В общем случае все сходятся на мнении, что это автоматизация, стандартизация и более активное участие отдела эксплуатации в разработке, но этих «всех» не так много, если считать в процентах от общего количества IT-людей. 3. Каковы преимущества DevOps? В случае успешного внедрения DevOps компании могут в перспективе рассчитывать на: автоматизацию (снижение рисков человеческой ошибки) ускорение и упрощение процессов разработки и релиза получение быстрой обратной связи от пользователей (метрики, мониторинг) PROFIT!!! 4. Каковы недостатки DevOps? Нужно очень много поработать. Нужно не забывать про до сих пор актуальные best practices предыдущих поколений – в море новых технологий сделать это легко. DevOps по разным причинам может не подойти коллективу, пытающемуся внедрить сабж. DevOps — не серебряная пуля (а жаль). 5. Насколько широко распространился DevOps в СНГ / России? В компаниях-лидерах IT-рынка — широко распространился. Хотя, как водится, есть исключения. Но живые компании все чаще понимают необходимость современных методологий. Евгений Потапов, генеральный директор ITSumma: 1 Каким компаниям подходит DevOps? Существует несколько значений термина, несколько пластов понимания, что же такое DevOps. Если мы говорим о культуре взаимодействия разработки и эксплуатации, где программисты понимают, как работают системы, и обладают навыками системного администрирования, а администраторы понимают принципы разработки, то это несомненно надо любой компании, поскольку такой плотный контакт обеспечивает простоту взаимодействия и скорость решения задач, которые часто лежат на границе этих областей. Если же мы говорим о наборе конкретных практик, связанных с виртуализацией, контейнеризацией, автоматизацией управления инфраструктуры, то здесь самое главное, что компания (а главное сам проект), должна достичь такого размера, при котором накладные расходы на организацию этих практик будут ниже, чем накладные расходы на управление инфраструктурой без них. 2 Насколько глубоко понимание DevOps в русскоговорящем сообществе? В наш 21-й век различия между сообществами разных стран не настолько сильны, как можно подумать. Да, мы несколько отстаем по времени начала применения новых технологий по сравнению, прежде всего с компаниями Долины, однако это вопрос месяцев, не лет. 3 Каковы преимущества DevOps? Упрощение коммуникации между специалистами ведет к ускорению взаимодействия. Пропадает классическая проблема, где программисты винят во всем работу серверов, а администраторы отвечают, что проблемы создает код. Ускоряется как создание новой функциональности, так и решение старых проблем. Автоматизация же позволяет избавить от извечной рутины и хаоса в ИТ-проектах. 4 Каковы недостатки DevOps? Самая главная проблема, которую мы сейчас видим связана не столько с самой методологией DevOps, сколько с повышенным вниманием и ажиотажем вокруг любой новой технологии или практики, когда они применяются не по необходимости, а из интереса к самой технологии. Зачастую накладные расходы на внедрение и поддержку практик автоматизации, таковы, что даже не ускоряют, а замедляют процессы внутри компании. Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню? При этом человеческие и денежные затраты на поддержание этой возможности довольно велики. 5 Насколько широко распространился DevOps в СНГ / России? Существуют развитые сообщества DevOps-специалистов, проходят митапы, выходят отличные книги: www.facebook.com/groups/feedme.ru www.facebook.com/groups/1418742661718580 devopsdeflope.ru telegram.me/devops_deflope eksmo.ru/book/proekt-feniks-roman-o-tom-kak-devops-menyaet-biznes-k-luchshemu-ITD583259 Авторы книги DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win выделяют следующие бизнес-преимущества DevOps: быстрый выход на рынок (сокращение времени цикла и более высокие темпы развертывания); повышение качества (повышение доступности, меньше сбоев и так далее); увеличение организационной эффективности (больше времени тратится на деятельность, связанную с увеличением ценности продукта и количества функционала). P.S. Возможно следующим этапом оптимизации командной разработки будет введение телепатической связи между сотрудниками всех отделов и даже с заказчиками.

Нас очень давно просили сделать API, который позволяет встраивать Панорамы Яндекса на свои сайты, и мы, наконец, смогли это сделать. Даже больше: наш API даёт возможность создавать собственные панорамы. В этом посте я расскажу, что вообще надо знать, чтобы делать такие виртуальные прогулки. Почему сделать API для них было не так-то просто, как мы разрешали разные встающие на пути проблемы и подробно объясню, что вы сможете сделать с помощью нашего API (больше, чем может на первый взгляд показаться). Движок Сервис панорам запустился на Яндекс.Картах в далеком сентябре 2009 года. Поначалу это были лишь несколько панорам достопримечательностей и работали они, как вы, наверное, догадываетесь, на Flash. С тех пор много воды утекло, панорам стало несколько миллионов, начали быстро расти мобильные платформы, а Flash туда так и не пробрался. Поэтому примерно в 2013 году мы решили, что нам нужна новая технология. И основой для этой технологии стал HTML5. API, с которого мы начинали, — это Canvas2D. Сейчас это может показаться странным, но в 2013 году этот выбор был вполне разумен. WebGL был стандартизован всего двумя годами раньше, толком еще не добрался до мобильных (в iOS, например, WebGL работал только в уже почти почившем в бозе iAd), да и на десктопах работал не очень стабильно. Читатель может мне возразить, что надо было все делать на CSS 3D, как это было тогда популярно. Но с помощью CSS 3D можно нарисовать только кубическую панораму, в то время как все панорамы Яндекса сферические (хранящиеся в равнопромежуточной проекции). Это же было и самой главной технической трудностью в разработке. Дело в том, что корректно и точно спроецировать сферическую панораму на экран непросто из-за нелинейности этого преобразования. Наивная реализация такой проекции требовала бы целого вороха тригонометрических вычислений на каждый пиксель экрана — ведь нужно найти соответствующую ему точку в панорамном изображении и определить его цвет. Кроме того, Canvas 2D не предоставляет эффективного способа манипулировать каждым пикселем изображения по отдельности. На помощь в этой непростой ситуации приходит один из самых старых трюков в компьютерной графике — линейная интерполяция. Мы не будем для каждого пикселя экрана точно вычислять координаты соответствующей точки в панорамном изображении. Мы это сделаем лишь для некоторых пикселей, которые выберем заранее — а для остальных станем находить координаты, интерполируя между уже рассчитанными. Вопрос лишь в том, как выбрать эти пиксели. Как уже было замечено, записывать цвет изображения попиксельно в Canvas2D неудобно, но удобно работать с изображениями и их двумерными трансформациями. Кроме того, такие трансформации фактически реализуют интерполяцию за нас. Именно их и решено было использовать в качестве основы алгоритма рендеринга панорамы. А так как двумерная линейная трансформация однозначно задается двумя триплетами точек, один на экране, а другой на панорамном изображении, то выбор набора точек, для которых мы будем считать проекцию точно, получается сам собой: будем разбивать панорамную сферу на треугольники. Итоговый алгоритм рендеринга получился следующим: Написав все это и запустив, я увидел нечто, хорошо описываемое словом «слайдшоу». Фреймрейт оказался совершенно неприемлемым. Попрофилировав, я нашел, что больше всего времени отъедают функции save() и restore() Canvas 2D контекста. Откуда они взялись? Из особенности работы с обрезкой в Canvas2D. К сожалению, чтобы иметь возможность сбросить текущую обрезку и выставить новую, необходимо сохранить перед выставлением состояние контекста (это как раз save()), а после всего необходимого рисования восстановить сохраненное состояние (а это уже restore()). А так как эти операции работают со всем состоянием контекста, они недешевы. Кроме того, обрезку-то мы делаем каждый раз совершенно одинаковую (после инициализации разбиение сферы на треугольники и их наложение на панорамное изображение не меняются). Есть смысл это закешировать! Сказано — сделано. После генерации триангулированной сферы мы «вырезаем» каждый треугольник из панорамного изображения и сохраняем его в отдельном кеше-канвасе. Остальная часть такого кэша при этом остается прозрачной. После такой оптимизации удалось получать 30—60 кадров в секунду даже на мобильных устройствах. Из этого опыта можно извлечь следующий урок: при разработке рендеринга на Canvas 2D все, что можно, кэшируйте и пререндерите. А если что-то вдруг нельзя — делайте так, чтоб было можно, и тоже пререндерите. У любого кеширования (как и у многих вещей в этой жизни) есть и обратная сторона: неизбежно растет потребление памяти. Именно это и произошло с рендерингом панорамы. Возросшие аппетиты породили множество проблем. Самыми заметными можно назвать падения браузеров даже на декстопных платформах, а также довольно медленный старт. В конце концов, устав бороться с этими проблемами, мы отказались от репроецирования панорамного изображения на Canvas 2D и пошли другим путем. Но он уже совершенно не интересный :) Однако еще до того мы начали смотреть с сторону WebGL. К этому нас подтолкнули разные причины, главной из которых, пожалуй, была iOS 8, в который WebGL заработал в Safari. Главной проблемой при разработке WebGL-версии рендеринга был размер панорам. Панорамное изображение целиком не лезло ни в одну текстуру. Эту проблему мы снова решали, руководствуясь принципом «руководствуйся старыми как мир принципами», и разделили панорамную сферу на сектора. Каждому сектору соответствует своя текстура. При этом для экономии памяти и ресурсов GPU невидимые сектора полностью удаляются. Когда они должны на экране появиться вновь, данные для них снова перезагружаются (обычно из кеша браузера). Встраивание панорам Встраивание панорам с помощью API Карт начинается с подключения нужных модулей. Это можно сделать двумя способами: либо указав их в параметре load при подключении API, либо с помощью модульной системы (в скором времени мы добавим модули панорам в загружаемый по умолчанию набор модулей). <!-- Указываем нужные модули панорам при подключении API. --> <script src="https://api-maps.yandex.ru/2.1/?lang=ru_RU&amp...layer"></script> <script> // Подключение с использованием модульной системы. ymaps.modules.require([ 'panorama.createPlayer', 'panorama.isSupported' ]) .done(function () { // ... }); </script> Перед началом работы с панорамами необходимо убедиться, что браузер пользователя поддерживается движком. Это можно сделать с помощью функции ymaps.panorama.isSupported: if (!ymaps.panorama.isSupported()) { // Показываем пользователю сообщение, скрываем функциональность // панорам, etc. } else { // Работаем с панорамами. } Чтобы открыть панораму, нам сначала надо получить ее описание с сервера. Это делается с помощью функции ymaps.panorama.locate: ymaps.panorama.locate( [0, 0] // координаты панорамы ).done(function (panoramas) { // ... }); Результатом, которым разрешится промис, возвращаемый вызовом ymaps.panorama.locate, будет массив панорам, находящихся в некоторой окрестности переданной точки. Если ни одной такой панорамы нет, массив будет пуст. Если таких панорам будет найдено несколько, они будут отсортированы по расстоянию от переданной точки. Первая при этом будет ближайшей. Еще можно запрашивать воздушные панорамы: ymaps.panorama.locate( [0, 0], // координаты панорамы { layer: 'yandex#airPanorama' } ).done(function (panoramas) { // ... }); Получив описание панорамы, мы можем создать плеер, который отобразит ее на странице: var player = new ymaps.panorama.Player( 'player', // ID элемента, в котором будет открыт плеер panorama // Панорама, которую мы хотим отобразить в плеере ); И мы увидим на странице: Самый быстрый и простой способ открыть панораму — это функция ymaps.panorama.createPlayer: ymaps.panorama.createPlayer( 'player', // ID DOM-элемента, в котором будет открыт плеер [0, 0] // Координаты панорамы, которую мы хотим открыть ).done(function (player) { // ... }); При этом можно указать одну или несколько опций третьим параметром: ymaps.panorama.createPlayer( 'player', [0, 0], { // Слой, в котором искать панораму layer: 'yandex#airPanorama', // Направление взгляда direction: [120, 10], // Угловой размер видимой части панорамы span: [90, 90], // Набор контролов controls: ['zoomControl', 'closeControl'] } ).done(function (player) { // ... }); После создания плеер предоставляет компактный API для управления отображением панорам и подписки на пользовательские события. Но, как мне кажется, это не самая интересная возможность API панорам. Свои панорамы Пожалуй, самая интересная возможность, которую дает API, это создание собственных панорам и встраивание их на сайт. Любая панорама начинается со съемки и подготовки панорамного изображения. Для съемки можно воспользоваться специальным устройством, обычным фотоаппаратом или даже смартфоном. Главное, чтобы результатом съемки и склейки была сферическая панорама в равнопромежуточной проекции. Например, стандартное приложение камеры на Android умеет снимать и склеивать панорамы в нужной проекции. Именно им мы и воспользовались для съемки панорам нашего уютного опенспейса. После того как мы сняли панорамное изображение, необходимо его подготовить к отображению в плеере. Для этого нам нужно разрезать его на тайлы. Кроме того, мы можем подготовить изображения нескольких разных размеров для разных уровней мастабирования. Плеер будет выбирать самый подходящий уровень для текущего размера DOM-элемента, в котором открыт плеер, и угловых размеров видимой области панорамы. А если самый маленький уровень меньше 2048 пикселей по ширине изображения, он будет использован для создания «эффекта прогрессивного джипега». Плеер подгрузит тайлы этого уровня с самым высоким приоритетом и будет показывать их там, где нет тайлов лучшего качества (например, если они еще не загружены или были вытеснены из памяти и пока не перезагрузились). Для нарезки изображений на тайлы можно воспользоваться любым ПО (при наличии определенной усидчивости — хоть Paint). Размеры тайлов должны быть степенями двойки (те из вас, кто работал с WebGL, думаю, догадываются, откуда растут ноги у этого ограничения). Я воспользовался ImageMagick: # Сначала немного растянем исходное изображение так, чтоб оно разбивалось # на целое число тайлов по горизонтали (по вертикали это, кстати, не обязательно). $ convert src.jpg -resize 7168x3584 hq.jpg # Разрежем изображение на тайлы размером 512 на 512 пискелей. $ convert hq.jpg -crop 512x512 \ -set filename:tile "%[fx:page.x/512]-%[fx:page.y/512]" \ "hq/%[filename:tile].jpg" # Подготовим уровень масштабирования низкого качества для «эффекта # прогрессивного джипега». Он будет состоять из одного тайла, поэтому его # не надо будет разрезать. $ convert hq.jpg -resize 512x256 lq/0-0.jpg Давайте наконец напишем уже какой-то код для нашей панорамы. API — это система связанных между собой интерфейсов. Эти интерфейсы описывают объект панорамы и все связанные с ним. Давайте теперь разберем эту картинку по сущностям. Объект панорамы должен реализовывать интерфейс IPanorama. Чтобы написать свой класс панорамы было проще, сделан абстрактный класс ymaps.panorama.Base. Он предоставляет разумные реализации по умолчанию для некоторых методов IPanorama, а также метод validate, который проверяет, удовлетворяет ли панорама ограничениям, накладываемым плеером (например, является ли указанный размер тайлов степенью двойки). Давайте им и воспользуемся. function Panorama () { Panorama.superclass.constructor.call(this); // ... // И проверим, что мы все делаем правильно. this.validate(); } ymaps.util.defineClass(Panorama, ymaps.panorama.Base, { // Методы, возвращающие данные панорамы. }); Начнем мы с того, что опишем плееру геометрию панорамы. Для этого нужно реализовать метод getAngularBBox, возвращающий, судя по документации, массив из четырёх чисел. Каков смысл этих чисел? Чтобы ответить на этот вопрос, вспомним про то, что панорама у нам сферическая, то есть наложенная на сферу. Чтобы описать положение панорамного изображения на сфере, необходимо выбрать некоторые «опорные» точки. Обычно для прямоугольника (а панорамное изображение, не будучи на сфере, как раз им и является, как и любое изображение в компьютере) выбирают координаты двух его противоположных углов. В нашем случае этот подход продолжает работать и на сфере, ведь вертикальные стороны изображения становятся при наложении меридианами, а горизонтальные – параллелями. Это значит, что каждая сторона прямоугольника имеет собственную угловую координату, общую для всех точек этой стороны. Именно эти координаты сторон и составляют массив, возвращаемый методом getAngularBBox, определяя своего рода сферический прямоугольник, ограничивающий панораму (отсюда и названия метода). Плеер накладывает важное ограничение на геометрию панорамы (а значит — на само панорамное изображение): панорамное изображение должно смыкаться на сфере по горизонтали, образуя полный круг. Для значений, возвращаемых методом getAngularBBox, это значит, что разница между правой и левой угловой границей панорамы должна составлять 2?. Что касается вертикальных границ, то они могут быть любыми. Панорама, которую мы сняли смартфоном, не только полная по горизонтали, но и по вертикали, то есть от полюса до полюса. Поэтому границами панорамы на сфере будут интервалы [?/2, -?/2] по вертикали (от верхнего полюса до нижнего) и [0, 2?] по горизонтали (тут мы для простоты полагаем, что направление на стык панорамы совпало с направлением на север, что, конечно же, в действительности не так). Получается вот такой код: getAngularBBox: function () { return [ 0.5 * Math.PI, 2 * Math.PI, -0.5 * Math.PI, 0 ]; } Также нужно реализовать методы, возвращающие позицию панорамы и систему координат, в которой она задана. Эти данные будут использованы плеером для корректного позиционирования в сцене объектов, связанных с панорамой (о них ниже). getPosition: function () { // Для простоты выберем начало координат в качестве положения панорамы, ... return [0, 0]; }, getCoordSystem: function () { // ...а системой координат выберем декартову, чтоб наша панорама не // плавала где-то в Гвинейском заливе. return ymaps.coordSystem.cartesian; }, Теперь мы опишем сами панорамные изображения — как они разрезаны на тайлы и где эти тайлы лежат. Для этого нам надо реализовать методы getTileSize и getTileLevels. С первым все очевидно: он возвращает размер тайлов. getTileSize: function () { return [512, 512]; } getTileLevels возвращает массив объектов-описаний уровней масштабирования панорамного изображения. Их у нас, напомню, было два: высокого (относительно) и низкого качества. Каждый такой объект-описание должен реализовывать интерфейс IPanoramaTileLevel, состоящий из двух методов: getImageSize и getTileUrl. Для простоты не будем заводить отдельный класс для этого, просто вернем объекты с нужными методами. getTileLevels: function () { return [ { getTileUrl: function (x, y) { return '/hq/' + x + '-' + y + '.jpg'; }, getImageSize: function () { return [7168, 3584]; } }, { getTileUrl: function (x, y) { return '/lq/' + x + '-' + y + '.jpg'; }, getImageSize: function () { return [512, 256]; } } ]; } На этом минимальное описание панорамы готово, и плеер сможет ее отобразить: var player = new ymaps.panorama.Player('player', new Panorama()); Кстати, такое минимальное описание панорамы можно сделать быстрее и проще с функцией-хелпером ymaps.panorama.Base.createPanorama: var player = new ymaps.panorama.Player( 'player', ymaps.panorama.Base.createPanorama({ angularBBox: [ 0.5 * Math.PI, 2 * Math.PI, -0.5 * Math.PI, 0 ], position: [0, 0], coordSystem: ymaps.coordSystem.cartesian, name: 'Наша супер-панорама', tileSize: [512, 512], tileLevels: [ { getTileUrl: function (x, y) { return '/hq/' + x + '-' + y + '.jpg'; }, getImageSize: function () { return [7168, 3584]; } }, { getTileUrl: function (x, y) { return '/lq/' + x + '-' + y + '.jpg'; }, getImageSize: function () { return [512, 256]; } } ] }) ); Кроме собственно самой панорамы плеер умеет отображать три вида объектов: маркеры, переходы и связи. Маркеры позволяют обозначать объекты на панораме (например, маркеры с номерами домов на панорамах Яндекса). Объект маркера должен реализовывать интерфейс IPanoramaMarker. Этот интерфейс содержит всего три метода: getIconSet, getPosition и getPanorama. Назначение последних двух вполне понятно из их названий. Первый же я вижу необходимым пояснить. Дело в том, что маркер – это интерактивный элемент. Он меняет состояние, реагируя на пользовательские события. Эти состояния и то, как они изменяются по событиям в UI, можно писать такой диаграммой: Например, маркер, обозначающий дом. Вот его состояние по умолчанию, состояние при наведенном курсоре и раскрытое состояние: Именно иконки этих состояний и возвращает плееру метод getIconSet. Иконка может быть как загружена с сервера (именно для этого этот метод и сделан асинхронным), так и процедурно сгенерирована (с помощью канваса). В нашем примере мы предположим, что в панораме один маркер и его иконки уже загружены: getMarkers: function () { // Как и с уровнями масштабирования, не будем создавать отдельный // класс, вернем объект. var panorama = this; return [{ properties: new ymaps.data.Manager(), getPosition: function () { return [10, 10]; }, getPanorama: function () { return panorama; }, getIconSet: function () { return ymaps.vow.resolve({ 'default': { image: defaultMarkerIcon, offset: [0, 0] }, hovered: { image: hoveredMarkerIcon, offset: [0, 0] } // Кстати, не обязательно указывать все состояния, // обязательно только `default`. }); } }]; } Переходы — это те самые стрелки, по клику на которые плеер переходит на соседнюю панораму. Объекты, описывающие переходы, должны реализовывать интерфейс IPanoramaThorougfare: getThoroughfares: function () { // И опять мы поленимся писать классы :) var panorama = this; return [{ properties: new ymaps.data.Manager(), getDirection: function () { // Переходы задаются не координатами, а направлением на // панораму, с которой переход связывает текущую. return [Math.PI, 0]; }, getPanorama: function () { return panorama; }, getConnectedPanorama: function () { // Именно этот метод будет вызван при переходе. // Кстати, свою панораму вполне можно связать с панорамой // Яндекса, получив ее с помощью метода ymaps.panorama.locate. return ymaps.panorama.locate(/* ... */) .then(function (panoramas) { if (panoramas.lengths > Связи являются своего рода гибридом маркеров и переходов: выглядят они как первые, а ведут себя как последние. В коде они реализуются точно так же, как и маркеры, но с добавлением метода getConnectedPanorama (см. IPanoramaConnection). Вместо заключения API панорам пока что запущен в статусе бета. Встраивайте, тестируйте на своих сайтах и приложениях, рассказывайте нам об этом в клубике, группе во ВКонтакте, Фейсбуке или через поддержку. Вот ЦИАН уже :)

18 июля 2016 года вступили в силу новый Административный регламент предоставления государственной услуги по государственной регистрации программы для ЭВМ, а также новые Правила регистрации программ и баз данных. Таким образом, прекращает действие Административный регламент 2008 года. Понятно, что если вы по каким-то причинам регистрируете программы в Роспатенте (зачем их регистрировать — мы обсуждали здесь ранее), то с 18 июля нужно пользоваться новой формой заявления. Больший интерес представляет анализ нового Регламента с целью понять, есть ли что-то существенно новое в регистрации программ, улучшающее или ухудшающее положение заявителей. Форма подачи документов Некоторые изменения связаны с появлением новых каналов связи с Роспатентом. Например, в Регламенте есть ссылки на электронную подачу заявок через сайт Роспатента и портал Государственных услуг (видимо, поэтому Роспатент ограничил максимальное время ожидания в очереди при физической подаче документов 15-ю минутами, п.33 Регламента). Срок регистрации Срок по государственной регистрации программы для ЭВМ или базы данных и выдачи свидетельства составляет теперь шестьдесят два (62!) рабочих(!) дня с даты приема заявки (п.13 Регламента). Ранее предусматривался двухмесячный срок на проверку наличия в заявке на регистрацию необходимых документов и материалов и их соответствия установленным требованиям. Чем вызвано увеличение простой процедуры регистрации на целый месяц? Если воспринимать замену терминов буквально, государственная услуга предоставляется не автоматически после проверки документов. Два месяца и так выглядело слишком большим сроком, а теперь еще дополнительный месяц. Ок, может за этот месяц с заявкой будут делать какие-то полезные процедуры? Смотрим дальше… Дополнительные документы к заявке Предоставление документов, подтверждающих уплату государственной пошлин, давно не является обязательным, и теперь это закреплено и в Регламенте. Однако, по желанию заявитель может приложить такой документ и выписку из ЕГРЮЛ (п.21-22 Регламента). В целом, предоставление таких документов ускоряет процесс регистрации. Депонирование кода программы (самое ценное нововведение) Ранее мы писали, что самое ценное в процедуре регистрации – это депонирование куска кода. По старому регламенту материалы, идентифицирующие программу для ЭВМ, представлялись в форме распечатки исходного текста (полного или фрагментов) в объеме до 70 страниц (и не страницей больше). Только вот такой объем часто вызывал недоумение, так как по такому небольшому куску не всегда можно установить идентичность программы в случае спора. Самым ценным нововведением, на наш взгляд, стали изменения требований к депонируемым материалам. В соответствии с новыми Правилами депонируемые материалы, идентифицирующие программу для ЭВМ, «представляются в форме исходного текста (полного или фрагментов) или иной форме, присущей языку программирования, на котором написана представленная на регистрацию программа для ЭВМ, в объеме, достаточном для ее идентификации» (п. 27 Правил). То есть, длину фрагмента определяет заявитель, и если, по его мнению, для идентификации требуется более 70 страниц, то Роспатент должен его принять. Помимо это, допускается включать в состав депонируемых материалов подготовительные материалы, полученные в ходе разработки программы для ЭВМ, а также порождаемые ею аудиовизуальные отображения в любой визуально воспринимаемой форме. Депонирование базы данных Ограничение на 50 страниц для баз данных также отменили. К депонируемым материалам, идентифицирующим базу данных, следует дополнительно прилагать «материалы, объективно подтверждающие количественное содержание базы данных, а именно наличие в представленной на регистрацию базе данных не менее десяти тысяч самостоятельных информационных элементов (материалов), составляющих содержание базы данных, и (или) документы, подтверждающие существенные финансовые, материальные, организационные или иные затраты, потребовавшиеся на создание базы данных». В качестве материалов, подтверждающих количественное содержание базы данных, могут быть представлены скриншоты отчетов, подготовленных СУБД, с указанием числа выявленных информационных элементов и (или) в форме нумерационных списков. При подаче заявки на регистрацию на бумажном носителе депонируемые материалы, исключая реферат, представляются в электронной форме на машиночитаемом носителе в формате PDF/A. Если представленная на регистрацию база данных содержит аудио-видео материалы, то примеры таких материалов представляются в форматах MP3, AVI, MPEG 2, JPEG (Раздел III Правил Оформления). К «машиночитаемому носителю» требования также прописаны: не должен допускать последующую запись на него информации и должен позволять осуществлять многократное считывание записанной на нем информации; и должен быть подписан (п. 15 Правил составления документов). Требования к реферату Расширен перечень того, что должно включаться в реферат: • Для программы для ЭВМ могут быть отражены особенности типа реализующей ЭВМ или другого компьютерного устройства, тип и версия операционной системы. • Для базы данных обязательно указывается, совокупность каких самостоятельных материалов она содержит. • Если программа для ЭВМ или база данных содержит персональные данные, об этом указывается в реферате. • Если программа для ЭВМ или база данных является частью составного произведения, приводится название составного произведения. • Реферат должен завершаться указанием: — языка программирования, на котором написана программа для ЭВМ; — системы управления регистрируемой базой данных (СУБД); — объема программы для ЭВМ или базы данных в машиночитаемой форме в единицах, кратных числу байт. И всё это – не более 900 знаков. И понятным языком без ненаучных терминов. Правила предписывают. Подтверждение авторства и прав Самым больным вопросом в процедуре регистрации программ была достоверность данных. Пример с Windows Vista уже всем надоел. Но возможно ли повторить такую провокацию с новым Регламентом? Пункт заявки, в соответствии с которым необходимо «внести краткое описание творческого вклада автора при создании регистрируемой программы для ЭВМ или базы данных», к сожалению, не получил разъяснений. Каким образом проверить, что автор что-то внёс, а тем более, что-то творческое – неизвестно. Сам Роспатент такую проверку проводить не будет. Если наличие этого пункта направлено на исключение «ложных» авторов, потому что заявители постесняются врать об отсутствующем творческом вкладе, то и моральная дилемма решается легко: в форме ходатайства об изменении списка авторов вопрос о творческом вкладе отсутствует. Получается, автором можно по-прежнему указать кого угодно, главное – уплатить пошлину. Авторов можно поменять после регистрации Регламент предусматривает возможность подать заявление об изменении состава авторов. Такое действие не связано с внесением изменений в саму программу или базу данных. Если в изначальной заявке указано, что творческий вклад автора состоял в написании, условно, конкретных 10 страниц кода, непонятно, нужно ли исключать эти страницы, если этот человек исключается из состава авторов, а код представляет ценность и без его части. Персональные данные Также в заявке и реферате необходимо указывать, содержатся ли в программе или базе персональные данные. П. 15 Правил оформления предусматривает необходимость указывать регистрационный номер заявителя (правообладателя) в Реестре операторов, осуществляющих обработку персональных данных. Вывод В целом, радикальных изменений регулирование не претерпело. Это уже хорошо. Как и раньше смысл регистрации программы — в депонировании материалов. Благо задепонировать программу сейчас можно более качественно. Плохо, что по-прежнему Роспатент не анализирует и не проверяет содержание заявления, ответственность за информацию в котором несёт заявитель. Поэтому всё ещё можно вслед за Vista успеть зарегистрировать Pokemon Go. Регистрация – всё ещё подтверждение даты создания кода, но не прав на этот код. На программы для ЭВМ и базы данных по этой процедуре вы не получаете аналог патента, предполагающий экспертизу и оценку. Сложно сказать, хорошо это или плохо, если бы Роспатент взялся за оценку программ по существу, еще не известно, чтобы из этого вышло. В любом случае, закреплены более удобные способы подачи заявок, размер кода, который можно зарегистрировать, увеличился, форматы документов расширились, только вот сроки регистрации выросли (можно надеяться, что из-за более тщательной проверки).

BPM «Как есть» и «как не есть» Продолжаем размышлять «что такое BPM», это который «Business Process Management» и какие они бывают. Парадокс: про него столько уже десятилетиями понаписано — книжек, статей, дискуссий, но что это такое – сегодня так и остаётся загадкой, причем: чем больше пишут – тем более загадочнее становится. Не помогают ни книжки из серии «Для чайников», ни заветы CBOK, ни магические квадраты от Гартнера (BPM: BPA, BPMS, iBPMS и т.п.), в которых, как и в черных квадратах Малевича (а у него только черных было несколько «разных» вариантов) – каждый норовит увидеть что-то великое и таинственное, ведомое только ему. В главе предлагается вариант классификации BPM-подобных сущностей. В информационной войне с «алхимией 21 века» продолжаем развенчивать популярные мифы о Business Process Management, Enterprise Architecture (ЕА) и иже с ними. Делаем очередной шаг на пути становления BPM как обычной (повседневной, повсеместной, тривиальной) инженерной дисциплины: process technology, «процесс-техника». Рекогносцировка В первой главе «Бизнес-процессы: Как все запущено и запутано» мы посмотрели на «BPM» глазами маркетинга и показали его ключевые мифы. На станицах cnews (см. комментарии к статье) подискутировали на тему «BPM – EA – Alchemy». Во второй главе попытались отделить «мух от котлет» и показали крайности (головы и хвосты): BPM это не про бизнес-менеджмент (там скорее что-то «из опер» BIZBOK-ов, BABOK-ов и т.п.) и не про «ИТ-фишки» (SOA, ESB и иже с ними). BPM даже не про автоматизацию, что на классических языках программирования (от «си», до «явы» под контролем SWEBOK-и), что на «новомодных» инструментах, — основанных на BPMN или даже на «ничего» («no code», где якобы кодить не нужно). Обсуждение второй главы с участием «Алхимика 80-го уровня» на bpmsoft.org Когда половина «умной книжки про BPM» посвящена SOA, ESB и т.п., думаешь: если их нет в компании, то и BPM в компании тоже невозможен? Или: будет ли «жить BPM» в компании, где нет (мало) автоматизации? На эту тему фрагмент из книжки Управление бизнес-процессами. Практическое руководство по успешной реализации проектов Глава 2 Что такое управление бизнес-процессами На этот вопрос надо ответить в самом начале, тем более что у каждого поставщика, аналитика, ученого, преподавателя, журналиста и клиента имеется свой ответ на него. Хотелось бы сразу разъяснить, что, по нашему мнению, BPM не приравнивается к технологическому инструментарию или инициативному проекту в области бизнес-процессов. Наш опыт подсказывает, что значительное усовершенствование бизнес-процессов может быть достигнуто и без применения технологий автоматизации. Послание «Чайникам» от IBM. Какие же откровения нам поведал голубой гигант в своей Business Process Management For Dummies, IBM Limited Edition? Введение и первая глава: написаны в стиле: «Счастливые обладатели BPM», «Только BPM может помочь вашей организации стать …» (выше, дальше, сильнее и т.п.) … супер-пупер и т.п. Причем в рекламной стилистике книжки так и напрашивается подмена созвучного термина «BPM» на «IBM», без какого-либо изменения смыслового содержания (точнее рекламы): «Если вы дочитали главу до этого момента, то вам теперь ясно, что BPM (точнее IBM) — это круто». Собственно этому подходу была посвящена целая глава «Бизнес-процессы: Как все запущено и запутано. Глава первая». Одним словом, всем «чайникам» после прочтения «BPM для чайников» должно стать ясно, что им очень нужен BPM (это же «круто»), но что это такое знать им не обязательно (в книжке я не нашел ответа). Остальные главы вторят то же самое и, конечно, далее дается «гениальный» вывод, что «IBM предлагает самый широкий спектр решений BPM». Неудивительно, что «правильный BPM» = IBM BPM. По секрету скажу, что настоящего BPM у IBM вообще нет. Послание «Чайникам» от нового хозяина ARIS. Продавать BPM нужно, поэтому не только вендоры, но и продажники делают книжки для «Чайников»: BPM Basics For Dummies Software AG Special Edition В указанных «основах» собрано все: адаптивные и гибкие процессы, визуализация и управление сквозными процессами в реальном времени (даже оркестровка и хореография процессов в real-time и кросс-функциональная видимость), «автоматизация — симуляция — оптимизация», связь по формуле {люди, информация, услуги, системы, процессы}. Конечно не забыты Непрерывное совершенствование процесса (CPI), Real-time monitoring (BAM), KPI-BSC и т.п., а также недавно «пришитые» к BPM: WYMIWYR и DMAIC. Типовая ошибка в книжке, где сказано, что «BPM является широкой дисциплиной». BPM должна быть «узкая», конкретная и понятная дисциплина. Только это позволит сделать ее практической и повсеместно применяемой инженерной дисциплиной. Вынесите смежные области, придумайте к BPM «чердаки» и «подвалы», составьте четкий стек BPM (по аналогии сетевым протоколам), но не нужно под вывеской «broad discipline» мешать все в одну кучу. Пока же нам преподносят «слишком большой BPM, что бы его можно было понять» (слишком большой, что бы его съесть). Если сперва сказали, что BPM — это «инфраструктура бизнеса» (это верно), то видимо этому и нужно следовать, а не смешивать инфраструктуру с бизнесовыми сущностями и не рассматривать в BPM «The BPM Business Architecture». 3 Общая классификация BPM 3.1 Популярные взгляды на классификацию BPM Одни говорят, что BPM — это просто философия менеджмента, позволяющая сфокусировать внимание на процессах или стратегия руководства для успешной трансформации бизнеса, другие, что это некая многоликая дисциплина: то ли документирования, то ли разработки, то ли внедрения, то ли еще чего, но под универсальным термином «дисциплина управления». Третьи (артисты видимо) уверяют, что это нечто, лежащее рядом с SOA и Web 2.0 и любят упоминать про оркестровку и хореографию. Чаще всего: BPM преподносится в «трех лицах», где бизнес-процесс: — задокументировали и проанализировали (design & analysis tools); — сымитировали и промоделировали (simulation engine); — развернули и исполнили (execution engine). Рядом стоит «прислуга»: dashboard, repository и т.п., а в VIP-ложе: CPI, BSC-KPI и т.п. Популярные, но «раскосые» взгляды профи на классы BPM (направления и соответствующие инструменты) предполагают цветную картинку из набора многочисленных и известных маркетинговых терминов. Показательный пример запутанности и не «простого и понятного» BPM приведен на рис. 3.1. Взгляд на BPM из KPMG Подобных архитектур и представлений о BPM много, как и этой: яркой, красивой картинке (дизайнерам – презентаторам пятерка), но непонятной. Рис. 3.1 Взгляд на BPM из KPMG На Рис. 3.2 показана картинка с www.what-is-bpm.com, где отражен более понятный (хоть и менее «художественно») подход к классификации BPM — инструментария. Рис. 3.2 Взгляд на BPM – инструментарий из what-is-bpm.com Картинка читается примерно так (немного с иронией, чтобы лучше донести ее суть): 1) от Understanding — понимания своих процессов («знай свой процесс»), что поддерживаются составлением карт процессов (Process Mapping) и инструментами документирования; 2) к совершенствованию процессов — через Analysis (куда же без анализов то?) и имитационное моделирование (не путать с просто «моделирование» = «документирование» в контексте Understanding); 3) к автоматизации \ модернизации (эдак их почти синонимами сделали) через BPMS разновидности, с интеграцией через SOA и разработкой «прикладных гибридов и композитов»; 4) и непременно, — все это «постоянно оптимизируя» и реинжинеря, снова оптимизиря и снова «переосмысливавшая коренным образом», т.е. зацикливая процесс на непрерывное – «вечное» совершенствование. Не понимаю, зачем так нужно – видимо в таком BPM «тормозов нет» (забыли предусмотреть), но во многих книжках именно так написано. К тому же, в чем отличие п. №4 от п. №2? Небольшая добавка: если ВСЕ ЭТО нужно для «небольшой тусовки» (workgroup), – то всего вышеуказанного «сыпь понемногу», а если для «крутого» Enterprise-Wide – то «помногу» (вектор «Scope» показывает «Масштаб»), плюс еще нужен репозита(о)рий процессов и некое «взаимодействие процессов» (самая верхняя «плюшка»). 3.2 Упрощенная классификация BPM-систем Учитывая разнообразие BPM-направлений исключим из рассмотрения BPM составляющие, непосредственно не относящиеся к описанию процессов, такие как: совершенствование (CPI), оптимизация, всевозможное не четко формализованное «управление» и т.п., а сконцентрируемся лишь на описании процессов и простейшем их анализе (без «бизнес-составляющей»). Т.е. BPM в терминах «процессный уровень», «процесс-техника», показанными во Второй главе настоящего цикла. Выделим три направления: — базовый BPM, «BPbase», — в основе которого лежат: — — формализация БП, «BPdoc» и — — вторичная обработка и анализ формализованных сущностей, BPana; — симуляция БП, «BPsim»; — исполнение БП, «BPexe». Задача BPdoc — формализовать процессы (показать образы реальных процессов в виде схем). BPsim — «оживить» процессы через динамическую модель процесса или отразить характеристики процесса на статических моделях (не описание и регламентация). BPexe — нужен чтобы получить исполняемый программный код, т.е. «сделать процесс программой». «Светлая мечта» любой автоматизации (мечта №1), включая BPexe «сделать сказку былью», — это когда ВСЯ логика «зашита» в исполняемом коде и вся работа оператора ЭВМ (участие в бизнес-процессе исполнителя) сведена к одному нажатию «большой красной кнопки». Рис. 3.3 Упрощенная классификация BPM-систем В исходном качестве Классификацию поясняет следующая «танковая» аналогия: — BPdoc — изображение танка как рисунка или чертежа. В случае эскиза или наброска, выполненного мазками (импрессионизм), — понятного только при взгляде «издалека» (с высоты птичьего полета, high-level). В случае рабочего чертежа (т.е. по которому можно работать) — как комплект конструкторской документации (танк в AutoCAD): возможна любая детализация, вплоть до всех размеров и разрезов (разрезов процесса), «поворот процесса» (можно «крутить» процессы) и т.п., картинка процесса в 3D (точнее в n — измерениях, плоскостях) и т.п. Это «конструкторская документация» на процесс (в терминах ЕСКД), процессная документация «в бумаге», рабочий проект на изделие «процесс», спецификация процесса и т.п. — BPsim — уменьшенная модель танка с дистанционным управлением: вроде бы игрушка, но «движется и стреляет пластмассовыми пульками». Такой танк похож на настоящий — все детали точь в точь (реплика), можно даже массогабаритный макет выполнить, но на фронт его не отправишь (только как ложную цель). Другой пример – это игрушки с «крутой физикой» типа World of Tanks или профессиональные авиа\авто\танковые-симуляторы. Тоже — все почти как настоящее, но входные данные (высота, скорость) — вымышленные (расчетные) и здоровью (реальному процессу) не навредить «если что-то пойдет не так». — BPexe — это уже настоящий танк, полученный из чертежей (BPMN 2.0), загруженных в 3D-принтер (BPMS). Загружай чертеж, печатай изделие (публикуй процессы в среде исполнения) и «на передовую» (развертывай программу в промышленную среду). Печать реальных танков пока еще в будущем (уже недалеком), но реальное стрелковое оружие уже печатают: Эволюция 3D-печатного оружия Примерно, как и в сегодняшнем BPMS: простые вещи изготавливаются в исполняемых BPMS-ках (и внедряются), но для сложных – используют традиционные технологии (классические системы программирования, готовые ERP/ECM и т.п.). Возможности современных BPMS – пока сильно ограничены, по прогресс не стоит на месте. Термин «BPMN» можно относить к другим «исполняемым» нотациям, включая оригинальные наборы значков (фигур) от наших «сэ один» и буржуйских «кэ два» (1С & K2). Не важно, как много они взяли непосредственно из начертаний стандарта BPMN 2.0, как правило, суть та же самая: «печать процессов на 3D-принтере BPMS» (некий Process Blueprint). 3.3 Подробности «BPbase — Bpsim — Bpexe» BPdoc основан на графическом представлении формализуемых процессов (моделирование в графических нотациях). Процесс на схемах обычно представляется в терминах потока работ (workflow), правил (логики ветвления) и потока информации (dataflow) и документов (docflow). Обычно инструменты BPdoc определяют как Business Process Modeling (тоже BPM) Tool. Но в понимании что «modeling» это не «simulation», т.е. «модель» – просто как схема со связями объектов входящих в нее объектов и хранящихся в общем репозитарии (архиве). Связность как с другими схемами, справочниками объектов (процессами и другими сущностями). BPdoc не включает: а) всю нормативную базу компании или даже полный комплект текстовых регламентов, т.к. подразумеваются лишь текстовые и графические «процессные вкрапления» (процессные регламенты); б) структуры, в составе (страшно произнести) Enterprise Architecture напрямую не связанные с процессами. В предельном случае BPdoc есть «большой» Processes Map, хотя не понимаю, как без текстовых описаний возможно полное описание процесса. Более точно, BPdoc — это операционная модель компании, под которой будем понимать связанное описание процессов (функций), должностей (ролей), документов (обрабатываемой информации) и инструментов (информационных систем, ИС). Как правило, подробное описание орг-структуры и ИС для этого не требуется, а достаточна лишь иерархия (иерархический справочник) с объектами, задействованными на схемах класса «облегченный EPC». В «облегченном EPC» из всего многообразия EPC (Событийная цепочка процессов) кроме «функции» и «события» ограничиваются 5-6 типами объектов: роль, документ, информационная система. Читать (описывать) конечный процесс без орг-штатной (ролевой) структуры, без набора (дерева) инструментов и без входящих \ выходящих (в \ из процесса) документов – неэффективно (малоинформативно). Исключения – схемы, показывающие логику ветвления. Поэтому нужна «обвязка» элемента «Функция» («окружение функции») и сводка этих обвязок в простенькой структурной схеме (хотя бы орг-штатной и структурной схеме ИС). Подробности см. в «Соглашении по моделированию» любого АРИС — проекта. Выше упор сделан на нотации для фиксации процессов (во главе с EPC), но в BPdoc применяются любые другие, в том числе, класса «исполняемые» (BPMN). BPM «исполняемый» (BPexe) содержит как минимум дизайнер (модуль разработки приложений) и «среду исполнения» (движок, BPM-Engine) и фактически представляет собой разновидность систем программирования. А именно, — направление «программирование без программирования» средствами визуального конструктора программ (хотя часто в BPMS требуется добавлять много кода). Такой процесс хоть и касается BPM, но ближе к среде программирования с графическим языком в виде BPM-нотации (BPMN) и с «исходником» в виде схемы процесса и экранных форм. Сегодня вендоры BPMS нас убеждают, что это «самый настоящий» BPM", но это была кража бренда «BPM» («лже-BPM» см. рис. 3.4). Рис. 3.4 Подделка термина BPM Разработчики и продажники «компиляторов новой волны» (BPMS, где — «графика в код») отобрали у системотехников (SE) бренд «BPM», а взамен бросили «кость» — BPA. Business Process Analysis Подмена проведена по сценарию: «дадут палец, руку откусим». «Сдача» (без боя) бренда BPM на «милость кодерам» (SWE) сопровождалась компрометацией исходных идей BPM — как управленческой методологии и высокоуровневых компонентов «Архитектуры предприятия», которые в программной инженерии или вообще не нужны или малозначимы (точнее у победителей «своя EA»). Это была ремарка к истории и философии BPMS в контексте противоречия «as is» vs «as really is». В итоге получился «лже-BPM» с сомнительными ориентирами на классический BPM, т.к. BPMN 2.0, like BPMN и другие исполняемые нотации пока: а) малоэффективны для бизнес-анализа (в сравнении с BPA), б) сомнительны для программирования силами бизнес-пользователей. Часто обычная автоматизация процессов «необычными» средствами разработки ПО — «исполняемыми BPMS», позиционируется как «удачный проект BPM» (лавры «чужой победы»). Уже подчеркивалось: прямой связи «BPM» и автоматизации — нет. Внедрение «исполняемой BPMS» и построение с помощью нее программы — это «типа BPM», а построение во встроенном BPM-редакторе (дизайнере) CRM, ECM, ERP такой же схемы процесса в похожей или такой же нотации — не считается внедрением BPM. Почему? Это просто Embedded BPM. Практически все современные CRM, ECM, ERP имеют конструкторы workflow, как минимум «похожие на BPM». Бизнес-процессы компании: ECM, CRM, BPM – какая разница? Внедрение нового приложения, собранного в дизайнере BPMS и запущенного на BPM-движке, мало чем отличается от классической автоматизации. Существует множество систем визуального программирования и конструкторов программ (включая мастер интернет-сайта и детский Scratch), где «программист» может не видеть ни строчки кода, что формально тоже BPMS — «no code». Основные принципы автоматизации современных BPexe (BPMS) представляют собой двадцатилетней давности аналог SCADA систем, используемых при автоматизации технологических процессов (в BPexe — административных, управленческих процессов). Такой же визуальный конструктор программ, с разницей, что вместо документов – электрические сигналы, а «живые исполнители» (роли) – это задвижки (исполнительные механизмы в АСУТП) или датчики. Во многих сегодня «уже давно немолодых» SСADA, включая отечественный TraceMode, изначально был подобный BPMS визуальный редактор [для «программиста», который не знал программирования], графическая схема технологического процесса, свой Business Activity Monitoring (BAM) — мониторинг, показывающий в реальном времени предельные (контрольные) и реальные значения температуры, давления, скорости, объема и т.п.: Система позволяет создавать сложные АСУТП вообще без программирования — в специальных графических редакторах, использующих терминологию, привычную для инженера-технолога. Где-то уже слышали нечто подобное, но про «бизнес-технолога»? Визуальное проектирование рабочего процесса компании (BPM) аналогично визуальному проектированию технологического процесса (АСУ ТП). Симуляторы BPM (BPsim) — в большинстве случаев, — это некая промежуточная категория между BPdoc (регламентом реального БП) и BPexe (реальной программы, т.е. автоматизированного БП и документированного, например, через BPMN). Симуляторы позволяют «почувствовать» динамику процесса (динамическое моделирование), запустить «упрощенные» экземпляры процесса. К сожалению для BPsim также как и для BPdoc используют термин «моделирование» (simulation — как имитационное моделирование), причем моделирование «бизнес-процессов» возможно как в «настоящих» BPA-BPMS (ARIS Simulation, PBexe), так и в универсальных (классических) системах моделирования. Моделирование возможно как посредством графических нотаций, признанных BPM-сообществом, так и в «непризнанных» или вообще средствами неграфических абстракций, включая языки моделирования, например, GPSS: Имитационное моделирование бизнес — процессов BPmon — средства «мониторинга процессов». 3.4 Причины популярности BPMS или «на пути к великой цели человечества»: создание программ без программистов При описании процессов средствами BPdoc, BPsim, BPexe ключевое слово — «графическая схема процесса». Хотя процесс можно описывать не только квадратиками или мощью русского языка: описание процесса буквами — он же текстовый процессный регламент. Для формализации процессов и событий существуют специализированные языки, особенно распространённые в системах имитационного моделирования, но они скорее придуманы для программистов, а не для аналитиков, методологов и других «фиксаторов и хирургов бизнес-логики от бизнеса». Даже несмотря на то, что некоторые языки содержат в своем названии заветное слово «бизнес-процесс», например, Business Process Execution Language (BPEL). Это относится и к «самым-самым великим» BPM-нотациям: Аббревиатура BPMN скорее расшифровывается не как Business Process Execution Language, а как «Business People May Not understand», то есть «люди бизнеса могут и не понимать» эту нотацию (Джим Синур) На протяжении долгих лет не угасает стремление (мечта №2) — найти простой путь моделирования процессов непосредственно их участниками (задействованными в процессе) без привлечения BPM-специалистов «по отрисовке квадратиков и кружков», а также выполнение построенных таким образом процессов. Отсюда и сильная тяга (надежда) к формату BPMS (BPexe). К сожалению, пока это остается мечтой, хотя периодически про нее вспоминают, например, именно под этой идеей стартовал BPMN. Но BPMN сильно проигрывает тому же EPC для целей фиксации и анализа алгоритмов на уровне бизнес-пользователей (критерий интуитивно-понятности) и «топов» и не достиг изначально поставленных целей. На трудно-читаемость BPMN также оказывает влияние вынужденная высокая детализация описываемого процесса: если в EPC можно за деталями отсылать в текстовый регламент, то в случае с исполняемым BPMN приходится «все нести с собой». Очередной виток делается «новым современным вызовом BPM»: S-BPM, парадигма «subject-oriented BPM» от очередного мавра (тоже немецкого профессора). Другой миф заключается в том, что раз используется BPMS, то на выходе «эффективность, помноженная на оптимальность». Ибо дизайнер процессов «шайтан-BPMS» сразу создает «эффективный процесс» (видимо через стелс-библиотеку гипер-когнитивного анализа), а среда выполнения BPMS делает бизнес-логику процесса оптимальной и «прямо на лету». «Уши растут» из гипотезы, что большинство программистов пишут программы не для человека, а для «себе подобных». Считается, что его программы удобны (понятны) только такому же программисту, а не целевому потребителю-пользователю (бизнес-подразделению). Популярна концепция, обеспечивающая «упаковку» алгоритма программы не в код, а в интуитивно понятные непрограммисту (методологу, пользователю) графические нотации и соответственно отсутствие, как кода, так и эффекта «испорченный телефон» на протяжении процесса разработки: Суровая правда любого нетипового проекта (качели) Более того, есть желание обеспечить работу полученной программы (исполнение) без участия ИТ-службы («публиковать» в «prod» по кнопке самим юзером). Как мы видим, реализация концепции еще далека от идеала, но и прогресс также нельзя отрицать в этом довольно древнем направлении «Программировании БЕЗ программирования» Указанные выше чаяния заключены в «трендах»: BPMS, «low-code», no-code" (программы с нулевым объемом кода, возможно появятся даже «с отрицательным кодом»). В реальности все проще: «Ничего личного, Просто маркетинг». Например, не принимают нас в ряды «настоящих BPMS», т.к. например, не поддерживается BPMN-нотация, значит, назовем это «low-code» (включая, «один сэ» и «кэ два»). Или хотим «открыть» новый рынок сбыта (фактически того же самого), то первыми «прыгаем» в тапки «code.net». Та же «один форма» (1forma.ru) позиционируется и как BPMS и как система управления класса Workflow, да и от «low-code» не открещивается — если покупателю так больше нравится. Часто продажи делаются примерно так: — Купите этого замечательного щенка! (soft) — А каких размеров он вырастет? — А Вам нужна большая собака? Да? Конечно, наш щенок вырастет и станет огромным псом! (BPMS) — Ах, Нет? Вам нужна крошечная собачонка? Так Вы нас неправильно поняли: наш щенок расти больше не будет — таким же и останется («low-code» & «no-code»)! Только купите его у нас! Ключевая «фишка» систем «low-code» — создание приложения, путем перетаскивания нужных функции из библиотек функций и построение логики приложения без необходимости кодирования с помощью визуального конфигуратора. Пока современные BPMS не очень дружат с «человекоподобными разрабами» (непрограммистами), поэтому подобно любым иным системам программирования (начиная от Си), они еще требуют много кода, а также с легкостью из «просто хаоса» делают «хаос автоматизированный». Последний еще опаснее. Были и остаются в моде (чаще мечтой) «делающие код» системы (в том числе, «no-code»), языки, нотации и другие абстракции (включая языки описания бизнеса, процессов и вообще жизни) для методологов бизнес-подразделений компании, т.е. инструменты не для IT-служб и программистов, а для рядовых «юзверей». Последние должны хотя бы легко читать свои процессы по этим нотациям и абстракциям. Иногда это называется «формализация на языке бизнеса», причем самим «Business user» (non-technical users). Нотации и абстракции должны быть практичными, стандартными и понятными даже непрограммистам (ребенку), но позволять построение моделей (описание), адекватных реально происходящим процессам. Интересно, что аналогичным путем развивается направление «программирование для детей», например, Мой опыт обучения детей 8-10 лет программированию на Scratch BPexe (BPMN, «low code» и прочее). Учитывая, что BPexe поддерживает как минимум стадии: моделирование, имплементацию (фактическую реализацию программы) и ее развёртывание, то модели под «exe» (execution) – по факту ВСЕГДА адекватны реальному процессу, причем автоматизированному. Обзор лидеров BPMS BPana, анализ процессов — «широкое» направление для творчества. Примером тривиального анализа может служить запрос к БД: сколько и где встречается такой то процесс (объект) или в каких процессах задействовано подразделение «А» или документ «Б»? Кстати, многие запросы можно делать и в системах класса «рисовалка», например, в Visio (там также использованы объекты и есть система поиска), а если к схеме процесса в Visio привязан файл Excel или Access с данными процесса, то возможности по тривиальному анализу могут быть сопоставимы с «крутыми» BPM, т.е. BPA и BPMS (в устоявшейся классификации). В любом случае BPana является «вторичным» и требует «первичку» — BPdoc. При этом, вдумчивый взгляд на карту процессов (BPdoc) — уже подразумевает «анализ» (BPana), поэтому грань иногда условна. 3.5 Леса, деревья, листья Процессы имеют разную детализацию. Как минимум: верхнего уровня и детального. Схемы (модели) класса BPexe — все детальные, иначе программа не заработает. Это «по определению», т.к. — «exe» = «execution». Но и детализация далеко не всегда хороша: «за деревьями — леса не видно», поэтому BPdoc можно разделить на две задачи (категории): задачу описания «леса» (процессы в «крупную клетку», взгляд с высоты «птичьего полета») и достаточно детальных «процессов — деревьев», но, как правило, еще не таких подробных, как в BPexe (BPMN), где формализуется каждая «гайка» (иначе «не взлетит»). Средствами BPMN можно описывать не только «листья» (гайки), но и «деревья», но никак не «лес». С одной стороны, за деталями (детальными процессами – «деревьями» в EPC и «листьями» в BPMN) теряется общая картина на весь процессный ландшафт предприятия (лес). С другой стороны, описать все «процессы — деревья» (не говоря о «листьях») также сложно, как и зарисовать, хотя бы схематично, все деревья даже в небольшом лесу. На эту тему — аналогия Карты процессов с географической картой: Дотошное описание бизнес-процессов — это хорошо или плохо? Полное описание бизнес-процессов крупной компании — это утопия. Во всяком случае, посредством современных технологий описания бизнес-процессов: что в виде многостраничных текстовых регламентов, что в виде квадратиков и кружков (моделей, нотаций). В первом случае, многотомные талмуды будут без связей и наглядного масштабирования (от high-level до «отправить уведомление по email»). Во втором, схемы EPC (BPMN, UML и т.п.) придется рисовать очень долго и большим составом рисовальщиков (бизнес-моделистов\ модельеров) и все-равно без гарантии получить «как есть в реальности» (см. картинку в заголовке статьи). Даже если все процессы автоматизированы с помощью BPMS (PBexe) и имеется полный комплект схем (моделей) процессов в BPMN, то для понимания «картины» в целом (показать «лес») их придется обобщать, укрупнять, систематизировать и т.п. Кроме того, оригинальные «рабочие процессы» (предельно детальные процессы) в формате BPMN, как уже отмечалось, будут непонятны большинству сотрудников бизнес-подразделений. В целом BPbase – это наука как по описанию и анализу леса, так и деревьев. И основная нотация для BPbase – это не BPMN, а скорее EPC (в прошлом IDEF). В инете много сравнений EPC vs BPMN. В целом если «лес» — высокоуровневые процессы — описать достаточно несложно (VAD, EPС, но не BPMN) и ценность такой работы наиболее высока, то детальные — «деревья» (EPC, для BPMN — не как «исполнение», а лишь как «иллюстрация») — колоссальный объем работы с уже меньшей ценностью (в задачах BPA), хотя бы потому что эти схемы дублируют (должны) текст инструкций (регламентов). Описывать «процессы для непосредственного исполнения» с помощью исполняемых нотаций типа BPMN — это формализовывать элементарные операции, т.е. все те, которые не требуют более детального описания, т.к. компилятор уже может переложить их в код. Если «тупой» компилятор может переложить схему в рабочий код, то это уже однозначный «финиш» детализации (предел для машины, человека иногда сложно остановить и он готов детализировать до бесконечности путем повторов). Внешне у процесса моделирования BPdoc (EPC) и BPexe (BPMN) много общего: визуально отличий мало – почти такие же квадратики и кружки. Во многом это и позволило заимствовать (прямым текстом — украсть) раскрученный термин «BPM». Хотя BPexe частично решает ту же задачу – документирование процесса (на рис. 3.3 результат «побочный», BPdoc'), но все же у них принципиально разные назначения и «собственная философия». Первым нужно показать человеку как примерно работает управленческий процесс («в целом», а многие детали – смотри в тексте регламента, поэтому в нем и «много букф»). Вторым — дать четкую инструкцию компилятору (пусть даже и через графические образы) «что делать» (а многие детали, все равно присутствуют только в коде). Со временем грань между BPexe (BPMS) и BPdoc (BPA) должна постепенно стираться. Возможно, из современного BPexe, который пока все-же «для программиста», выделится отдельный класс систем, который будет для «человека»: для бизнес-аналитика, не знающего вообще «страшных слов из мира ИТ». Другими словами: BPexe станет штатным инструментом бизнес-специалиста, а не программиста (ИТ-службы). Надеюсь, что такая же участь будет ждать и BPdoc: не нужно будет иметь штат «модельеров» (или нанимать EPC-консультантов), рисующих схемы процессов, а модели процессов будут генерироваться из штатных регламентов, возможно даже «незаметно» для пользователя. В совсем далеком будущем: автоматически – прямо из самого процесса по аналогии: топокарты по спутниковым снимкам («аэрофотосъемка» процессов компании) или раскрытие сетей (OpenView Network Node Manager и т.п.). Хотя бы научиться считать число процессов компании, наподобие — овец через спутники NASA, как в известной притче про консультантов («Около стада овец приземляется вертолет...»). Формализация процессов (BPdoc) имеет разные задачи: от тривиального регламентирования отдельных операций в графической форме до выстраивания Enterprise Processes Architecture. Иногда BPdoc проводится под последующую автоматизацию формализуемых процессов, т.е. является первой стадией Business process automation (не путать с «BPA», где «А» = analysis). Как подчеркивалось: описание процессов существует само по себе, вне зависимости — «автоматизированный процесс» или ручной и «будет ли он автоматизирован» или нет. При «автоматизации по схемам» (BPdoc), подготовленным в EPC (IDEF и т.п.) этот подход противопоставляется подходу «одним выстрелом двух зайцев» (PBexe), когда схемы под автоматизацию разрабатываются уже изначально в исполняемых нотациях BPMN и подобных, т.е. «execution». Выбор между BPA (EPC) или BPE (BP execution) в пользу последнего (BPMN) — не столь очевидный, как может показаться на первый взгляд: сложности восприятия «бизнесами» (специалистами не из мира ИТ) исполняемой нотации (BPMN и подобных), несовершенство самой технологии (инструментов BPMS). BP-BP (Business Process — Best Practice) — это не книжки типа BPM CBOK, а практические шаблоны и прототипы (в т. ч. просто примеры для тиражирования, типовые наборы процессов с детальным описанием), референтные модели из конкретной области, классификаторы процессов (например, APQC PCF Process Classification Framework) и т.п. В целом это основа, на которой может (должно) быть построено эффективное производство товаров (услуг), а не конвейер спекуляций. Это отдельная глобальная тема обсуждений о будущем BPM (хорошо забытым прошлом): Global BPM. 3.6 Близкие понятия Применительно к BPdoc, BPsim, BPexe можно отнести многое из терминов «Process [X]», где > — Model / Repository & Design / Documentation (как-то процессы же нужно формализовывать и куда-то их складывать). Не так важно разрабатывается процесс на будущее (to be) или документируется существующий (as is). Иногда это обзывают Process Understanding из серии – «знай свой процесс» (сравни: «знай своего клиента»); — Portal / Publisher (публикация процессов, совместная работа, «делись своими процессами» и т.п.); Для BPdoc часто используется «Process Map»/ «Process Mapping» (Картирование производственного процесса), выраженный или иерархическим деревом или графикой. Далее Process Map может быть использован как «подложка из процессов», на которую наносят некие метрики. Если на подложку наносить данные ВАМ, то получится мозаика индикаторов на фоне «процессной карты». Близкие названия Process Dashboard, BI Dashboard, Process Measurement и другие. BPana — к нему могут «присоседиться» многие из Business Process \ Performance Improvement, всего «самого непрерывного» улучшайзинга и просто реинжиниринга. Но это находится уже за пределами «чистого BPM». 3.7 За бортом «чистого BPM» Чтобы «не ломать копья»: «BPM это или нет», выделяем отдельной категорией BPMextra (extraordinary, «необыкновенные»), и «сольем» туда все, что не вошло в понимание «чистого BPM» (см. рисунок 3.3) и BPexe. Первый набор претендентов — это большинство терминов (модных «фишек») из «Hype Cycle for BPM» («кривая обмана») Второй — все что «приклеилось» к BPM(s) через ИТ («хвосты»), включая разнородные «BPM-интегрейшены» типа integration-centric BPM, ориентированные на интеграцию системы управления бизнес- процессами В категорию BPextra включим малопонятные и «звездные» термины и процессы под них: все BPM-окружение, связанное со «стратегией» (Business Strategy), «управление управлением» («руководство», Governance Mgmt., Process Governance), «отслеживанием стратегических целей развития бизнеса», «общекорпоративными правилами по управлению», в том числе, бизнес-процессами. Согласно терминологии Второй главы настоящего цикла — это «Business-ацетон» («головы» при процессе дистилляции BPM). Кто не может оторвать от BPM все «самое-самое» прогрессивное и принимает это как BPM, может включать это в BPextra: Кайзены, всеобщее управление качеством (TQM, СМК), «самые» бережливые производства Lean, «все сигмы» (Six Sigma и семь сигма, т.е. которые + Lean), и другие «совершенные» технологии всеобщего совершенствования, в том числе, совершенствования бизнес-процессов, но которые не основаны на документировании, регламентации и стандартизации конкретных бизнес-процессов компании. Классификацию методологий «трансформации», «совершенствования» (самого передового «улучшайзинга»), «Тойота» и т.п. см. Методология управления бизнес-процессами (BPM) К «самому-самому» прогрессивному и «like BPM» также примешивают: — Business-driven development, это такая методология, в которой разрабатываются ИТ-решения, непосредственно отвечающие требованиям бизнеса (видимо все остальные программы, построенные вне BDD, этому не отвечают и, следовательно, бесполезны); — x_BOK-и, особенно, где «х» включает заветное слово «Business»: — — BIZBOK (Guide to the Business Architecture Body of Knowledge) Обратите внимание, что там много чего — как из BPM, так и EA; — — REBOK (Requirements Engineering Body Of Knowledge), инженерия требований, там такие же Business Strategy, Business Case, Business Rule, Business Process и др.), — — BABOK iiba.ru/category/babok (Business Analysis Body of Knowledge), тоже инженерия требований, но позиционируется как бизнес-анализ «с целью выявления требований»), кстати, на указанном сайте приличная библиотека, в том числе, по разделу BPM; — Service-oriented modeling + «х», где «x» = «and architecture», тогда это уже SOMA, «x» = «framework», тогда SOMF, есть service-oriented analysis and design (SOAD), есть Service-oriented modeling sub-ontology (SOMsO) и конечно BPM sub-ontology (BPMsO) и много чего подобного в книжках подобных: «Service-Oriented Computing ICSOC/ServiceWave 2009 Workshops»; — и много-много подобного: иной раз создается впечатление, что любую технологию можно подвести под «многогранный» (многоликий) BPM. К BPextra («like BPM») отнесем «архитектурные картинки» из мира ЕА и все остальное «правильное и похожее» на BPM, но что не вошло в «pure BPM» (Natural BPM). Наводить порядок в самом BPextra будем в другой раз и видимо уже вне плоскости (layer) BPM. Ваш, bipiem

В посте собрана подборка обучающих уроков по созданию векторной графики. На мой взгляд большинство материалов покажутся интересными для новичков только начинающих постигать векторное искусство. Но думаю, что специалисты также смогут найти для себя полезные уроки. Туториалы бесплатные, но почти все на английском языке. Для удобства они поделены на три категории: приступая к работе, создание лиц, дизайн персонажей, ландшафт и окружающая среда и особые эффекты. Итак, поехали: Приступая к работе 1. Изучение векторной иллюстрации за 10 шагов В этом уроке объясняется, каким образом создавать векторные иллюстрации используя Adobe Illustrator. Приводится объяснение ключевых параметров и инструментов, которое дополняется советами экспертов. 2. Руководство для начинающих векторных художников В этом многогранном туториале Вы узнаете основные термины, рассмотрите рабочие процессы и техники, которые помогут начать работать с векторной графикой. 3. Инструмент «Перо» Инструмент «перо» — один из основных в арсенале программы, он особенно важен для начального овладения векторной графикой. Это подробное руководство ставит своей целью познакомить Вас с особенностями и методами работы с незаменимым инструментом компании Adobe. А также с наиболее рациональными способами его использования. 4. Рисование векторной графики Данный видео-туториал является действительно ценным ресурсом, который объясняет как создавать векторную графику в Illustrator и какую роль в этом процессе играет рисование. 5. Illustrator для начинающих: 11 лучших советов От использования точек кривой Безье до обводки, заливки и придания векторной графике более естественного вида — это лишь некоторые секреты Illustrator из урока, которые существенно пополнят арсенал новичка. 6. Создание простых органических форм в векторе Узнайте, как создавать простые органические формы в Illustrator с этим простым для восприятия руководством от Верле Питерс (Veerle Pieters), графического и веб-дизайнера. 7. Добавление текстуры для векторных иллюстраций Добавление текстуры — это отличный способ сделать Вашу векторную графику более выразительной, подчеркнуть ее перспективу. В этом очень доступном видео эксперт Illustrator Александра Сесилио (Alexandra Cecilio) демонстрирует как это сделать. 8. Создание линейного графика Этот туториал от Андрея Мариуса (Andrei Marius) поможет Вам создать векторный линейный график. Пошагово: начиная с простой сетки до направляющих линий, используя только панель Appearance (один из мощнейших инструментов в Adobe Illustrator) с добавлением некоторых простых фрагментов текста и тонкой штриховки. Создание лиц 9. Создание векторного глаза Это очень полезный видео туториал, который показывает процесс создания векторного глаза, а также затемнение кожи. 10. Векторные портреты для начинающих Это углубленный видео курс, который поможет в овладении искусством создания векторных портретов на основе фотографий. 11. Создание векторного портрета основанного на линиях Еще один замечательный туториал по векторной графике. Руслан Хасанов показывает как манипулировать работой векторных линий и градиентами, чтобы придать работе динамичность. 12. Как создать Геометрический, Векторный WPAP Портрет в Adobe Illustrator С возрождением геометрической тенденции, справедливо сказать, что WPAP может быть представлен в большем количестве различных аспектов дизайна. Этот туториал покажет Вам как самостоятельно создать WPAP в Illustrator с помощью мастера WPAP. 13. Как создать векторные волосы Прорисовка волос в векторе может быть довольно мудреной. Этот туториал шаг за шагом показывает как волосы с фотографии превращаются в векторные. 14. Создание автопортрета в геометрическом стиле В этом уроке Вы сможете создать иллюстрированный автопортрет в геометрическом стиле. В качестве основы иллюстрации будет использоваться Ваша собственная фотография. Она поможет нарисовать эскиз, а затем завершить оставшуюся часть работы. Дизайн персонажей 15. Создание аватаров профессии в Illustrator Иллюстратор и дизайнер Юлия Соколова показывает как создать набор портретов, которые идеально подходят для социальных медиа или, к примеру, для обозначения различных категорий и профессий на Вашем сайте. 16. Самый простой способ для создания причудливых персонажей в Illustrator Джонатан Болл (Jonathan Ball), основатель Poked Studio, обьясняет как с помощью Illustrator основные геометрические фигуры превращаются в уникальных, красочных персонажей. 17. Тематический урок на тему «Алиса в Стране чудес» В этом уроке Вы легко и весело создаете очень простой трафарет, который можно использовать на различных поверхностях (включая футболки, стены, холсты). Сказка Л. Кэррол «Приключения Алисы в Стране чудес» вдохновила автора на создание векторного изображения и написание туториала. 18. Как нарисовать и перевести в вектор Kawaii Vampire Chibi с помощью Illustrator С помощью этого туториала Мэри Винклер (Mary Winkler) собирается показать Вам, как нарисовать чиби персонажа с нуля, используя Shape Builder Tool (Shift-M), Pen Tool (P), прозрачные градиенты, и многое другие инструменты Illustrator. 19. Создание векторного аниме персонажа в Photoshop В руководстве описан процесс создания простого персонажа аниме от начала и до конца. 20. Как создать милого векторного кролика Узнайте как создаются милые кролики в этом туториале векторной графики. Тренинг использует простые формы и градиенты, которые легко применимы и к иллюстрациям других персонажей. 21. Создание клевого векторного йети в Illustrator Этот туториал представляет очень много основных форм для достижения действительно ловкого стиля иллюстраций. А затем «оживляет» йети с помощью палитры холодных цветов. 22. Как спроектировать и перевести в вектор набор персонажей для видео игр Здесь Вы сможете увидеть, как создаются персонажи видеоигр. У Вас будет возможность рассмотреть работу с первого эскиза и до самого финала. 23. Создание векторного монохромного портрета Иллюстратор и автор Шейрен Милн (Sharon Milne) показывает, как создать монохромный портрет с фотографии. 24. Создание ретро футболиста Если Вы заядлый любитель футбола, то этот туториал будет особенно кстати. В уроке Сергей Кандаков создает яркую иллюстрацию с эффектом стиля ретро. Ландшафт и окружающая среда 25. Создание векторной картны-инфографики В этом уроке от векторного художника Андрея Мариуса (Andrei Marius) показано, как можно создать простой дизайн карты в Illustrator. 26. Создаем эффектный ландшафт окружающей среды В этом туториале продемонстрировано, как создать в llustrator эффектный ландшафт окружающей среды. Для выполнения задания будет достаточно базовых знаний об инструментах программы. 27. Рисуем векторные цветы с помощью gradient mesh Очень простой и последовательный урок от Дианы Тома (Diana Toma), который показывает как нарисовать прекрасные цветы используя градиентные сетки (меш). Особые эффекты 28. Высокое напряжение — опасно для жизни! Создайте электрический текстовый эффект в Illustrator В этом пошаговом руководстве Вы изучите, как создать «электрический» текст в векторе. 29. Как создать портрет с drip-effect Том Мак (Tom Mac) показывает, как в Illustrator создать портрет с drip-effect, используя инструмент Pen и кое-какие дополнительные методы. 30. Создание нежного восточного узора в Adobe Illustator В этом учебном руководстве мы сделаем простой и красивый восточный паттерн в Adobe Illustrator, который будет состоять из различных объектов азиатской культуры. 31. Создаем винтажную векторную текстуру За прошедшие годы винтажные иллюстрации и ретро-стиль стали вновь популярными в дизайне. В представленном уроке разработчик Бен Стирс (Ben Steers) делится своими методами, которые помогут Вам преобразовать векторные рисунки в ретро-стиль. 32. Векторные скетч-рисунки С помощью Illustrator можно создавать безупречную векторную графику. Но порой требуются иллюстрации, напоминающие художественные эскизы, выполненные на скорую руку. В уроке показано, как нарисовать векторный рисунок в таком стиле. 33. Как создать сияющий текст Следуя этому туториалу Вы сможете создать эффект блеска в Adobe Illustrator. В основе иллюстрации заложены три эффекта: бумага для заметок, витраж и рваные края. С помощью быстрой трассировки они превращаются в блестящую векторную текстуру. 34. Полутона (Halftone) в векторе Полутон — способ воспроизведения монохромного изображения. Он базируется на специфике восприятия картины человеческим глазом для которого область изображения, заполненная крупными точками, ассоциируется с более темными тонами. И наоборот, область, заполненная точками меньшего размера, воспринимается как более светлая. Художник Крис Маквей (Chris McVeigh) покажет, как создать векторный полутон. 35. Создаем коронную эмблему Бэтмена в векторе В этом учебном руководстве Вы изучите, как создать графический логотип Бэтмена, используя простые формы в Adobe Illustrator. Используются простые инструменты, вроде Ellipse Tool (L) и Shape Builder Tool (Shift + M). 36. Конвертируйте растровое изображение в векторное Это учебное руководство Inkscape демонстрирует, как преобразовать растровое изображение в векторное при помощи функции Trace Bitmap. 37. Как создать векторный слайдер Слайдер — популярный элемент веб-дизайна. В данном туториале показан вариант создания слайдера в векторе. 38. Создание коллажа из векторных и растровых изображений Сиара Фелен (Ciara Phelan) продемонстрирует Вам как с помощью комбинирования векторных изображений и фотографий можно создать удивительный коллаж. 39. Простая трассировка фотографий В этом туториале от одной дизайнерской студии рассказывается как просто нарисовать и трассировать фотографию. Для создания реалистичной иллюстрации в примере используется простая градиентная заливка. 40. Как создавать векторную вышивку в Adobe Illustrator В этом учебном руководстве показано, как создать эффект вышивки крестиком в Adobe Illustrator. Для этого будет использоваться панель Appearance и образцы.
[Перевод] Новые возможности Intel Media Server Studio 2016

Истории с файндфейсом множатся от недели к неделе. Не так давно отгремела волшебная история с поиском ванильных экаунтов порнотелочек с целью их дальнейшего шантажа, дальше подошел скандал в шоколаднице, в которой снимали писающих девочек, опять же персонаж, который взялся раскручивать злодея, фигурантов находит файндфейсом. В истории с неким чуваком, которого развели по скайпу отправить непристойную фотку с МПХ, после чего сразу стали шантажировать. До файндфейса они не добрались, но схема, как понятно, вполне отрабатывается и в более анонимных каналах. Я, кстати, упустил из виду, а прогнали через софтину все старые истории с поиском чувака, который обворовывал гуманитарку на Горе и всякое такое, за последние года три общественность искала и не нашла вполне приличное кол-во людей. Тоже ждем новостей и вспышек спонтанного насилия. С точки зрения прекрасного, есть фотопроект петербургского фотографа Егора Цветкова. То, что мы в целом потеряли анонимность уже более-менее понятно. Давайте теперь разберемся, а есть ли у нас варианты повоевать на том фронте? Рассказываю: по пунктам Меня сфотографировали в общественном месте без разрешения – это законно? Да, законно. Закон запрещает обнародование и дальнейшее использование изображения гражданина (ст. 152.1 Гражданского кодекса РФ), но не запрещает саму съемку. То есть, если я вас сфотографировал, но фото потом не публикую, то я не нарушаю ваше право на изображение. Вообще законодательное регулирование права на изображение достаточно лаконичное – всего одна вышеупомянутая статья. В этой связи для выяснения большинства вопросов необходимо использовать судебную практику. К ней мы и обратимся для ответа на вопросы. Что понимать под обнародованием изображения, то есть под нарушением права? Цитата из Постановления Пленума Верховного Суда РФ от 23.06.2015 №25 (далее – Пленум): «Под обнародованием изображения гражданина… необходимо понимать осуществление действия, которое впервые делает данное изображение доступным для всеобщего сведения путем его опубликования, публичного показа либо любым другим способом, включая размещение его в сети «Интернет»». Если гражданин сам опубликовал в соцсети свое изображение, сделал его общедоступным, тогда его можно использовать по умолчанию? Пленум ВС РФ говорит, что нет. Цитируем: «обнародование изображения гражданина, в том числе размещение его самим гражданином в сети «Интернет», и общедоступность такого изображения сами по себе не дают иным лицам права на свободное использование такого изображения без получения согласия изображенного лица». Совсем-совсем нет? Ни при каких обстоятельствах? Не совсем. Опять цитируем Пленум: «Вместе с тем, обстоятельства размещения гражданином своего изображения в сети «Интернет» могут свидетельствовать о выражении таким лицом согласия на дальнейшее использование данного изображения, например, если это предусмотрено условиями пользования сайтом, на котором гражданином размещено такое изображение». Но тут дело в том, что большинству сайтов вы это согласие дали при регистрации. То есть — жопа. Какой вывод? Правильно – читайте условия пользования сервисами. А если не прочитали, то не удивляйтесь, если вас или вашего ребенка сделают лицом какой-нибудь сомнительной рекламной компании. Естественно не заплатят, вы же все уже разрешили ВКонтакте, Фейсбуку и любому другому сайту использовать ваши фото до начала использования сервиса любым способом без выплаты вам вознаграждения. В пользовательском соглашении это написано. Вы с ним согласились, не читая. Законно ли FindFace ищет ваши изображения? Считаю, что вполне законно. Во-первых, ваше изображение не публикуется сервисом. Программа просто сравнивает ваши изображения с миллионами других и находит похожие. Публиковать результаты сравнения – это нарушение, но просто показать их в приложении – нет. Во-вторых, программа находит изображения, которые вы скорее всего сами загрузили в свой профиль. Нарушением будет только использование незаконно обнародованных (то есть обнародованных без согласия гражданина) фотографий. Кстати, сам сервис как раз помогает найти такие незаконно опубликованные и используемые фотографии. Вот интересная история о похищении цифровой личности. По этой же ссылке много дельных советов как сделать свои изображения менее доступными для поиска. В-третьих, сервис не нарушает настройки приватности вашего аккаунта и не показывает фотографии, доступные только вам или друзьям. И, в-четвертых, у сервиса грамотное пользовательское соглашение. Обратите внимание на п. 4.4 – сервис обязывает пользователей пользоваться только легальными изображениями и в духе лучших практик соцсетей берет у вас безвозмездную лицензию на использование ваших изображений (п.4.5) и персональных данных (п.6). Все понятно, теперь я хочу запретить соцсетям использовать мои изображения – могу я передумать и как-то отозвать согласие? Верховный суд считает, что можно. Цитируем Пленум: «Ранее данное согласие гражданина на использование его изображения может быть отозвано в любое время. При этом лицо, которое обладало правом на использование данного изображения, может потребовать возмещения причиненных ему таким отзывом убытков (статья 15 ГК РФ)». Навскидку не видно, чем отзыв этого права может нанести сервису убыток. Но бы не зарекался. © Митягин, Готовцев

Предлагаю вашему вниманию перевод статьи «Introducing Slot-Based Shadow DOM API» автора Ryosuke Niwa, написанную им в блоге WebKit осенью прошлого года. Мы рады анонсировать что базовая поддержка нового Shadow DOM API на основе слотов, которую мы предлагали в апреле (прим. переводчика: речь идёт об апреле 2015) уже доступна в ночных сборках WebKit после r190680. Shadow DOM это часть Веб Компонентов – набора спецификаций, изначально предложенных Google для того чтобы сделать возможным создание переиспользуемых виджетов и компонентов в вебе. Shadow DOM, в частности, предоставляет легковесную инкапсуляцию DOM дерева, позволяя создавать на элементе параллельное дерево, так называемое «теневое shadow дерево», с помощью которого изменяется отрисовка элемента без изменения DOM. Пользователи такого компонента не смогут ненароком что-то в нём изменить, ведь его shadow дерево не является привычным потомком элемента-хоста. Кроме того, действие стилей также ограничено областью действия (scope), а значит CSS правила, объявленные снаружи shadow дерева не применяются к элементам внутри такого дерева, а правила, объявленные внутри – к элементам снаружи. Изоляция стилейПервое значительное преимущество использования shadow DOM – это изоляция стилей. Представим, что мы хотим создать собственный прогресбар. Например, следующим образом мы могли бы использовать два вложенных div'а для того чтобы представить сам прогресбар и ещё один div с текстом, в котором показывать процент выполнения: <style> .progress { position: relative; border: solid 1px #000; padding: 1px; width: 100px; height: 1rem; } .progress > .bar { background: #9cf; height: 100%; } .progress > .label { position: absolute; top: 0; left: 0; width: 100%; text-align: center; font-size: 0.8rem; line-height: 1.1rem; } </style> <template progress-bar-template').content.cloneNode(true); var progressBar = fragment.querySelector('div'); progressBar.updateProgress = function (newPercentage) { this.setAttribute('aria-valuenow', newPercentage); this.querySelector('.label').textContent = newPercentage + '%'; this.querySelector('.bar').style.width = newPercentage + '%'; } return progressBar; } </script> Обратите внимание на элемент template, использование которого позволяет автору включить сниппет HTML-текста, чтобы позже быть инстанциированным путём создания клона. Это первая фича «веб компонентов», внедрённая нами в WebKit; позже её включили в спецификацию HTML5. Элементу template в документе разрешено появляться в любом месте (скажем, между table и tr), а содержимое внутри template инертно и не выполняет скриптов и загрузку изображений или любых других ресурсов. Таким образом, пользователю сего прогресбара будет достаточно инстанциировать и обновлять его как показано ниже: var progressBar = createProgressBar(); container.appendChild(progressBar); ... progressBar.updateProgress(10); С такой реализацией прогресбара есть одна проблема: оба его div'а доступны любому желающему, а стили не ограничены только рамками самого элемента. К примеру, стили прогресбара, определённые для CSS класса progress будут так же применены и к следующему HTML: <section >Pending an approval</p> </section> А стили других элементов будут переопределять внешний вид прогресбара: <style> .label { font-weight: bold; } </style> Мы могли бы обойти эти ограничения, дав прогресбару имя custom element, например custom-progressbar чтобы ограничить область действия стилей, а затем проинициализировать все остальные свойства в all: initial, однако в мире Shadow DOM есть более элегантное решение. Основная идея в том, чтобы представить внешний div в качестве дополнительного слоя инкапсуляции так что пользователи не увидят что происходит внутри (создание div'ов для лейбы и самого ползунка), стили прогресбара не будут вмешиваться в работу остальной страницы и наоборот. Для этого нам понадобится сначала создать ShadowRoot, вызвав метод attachShadow({mode: 'closed'}) у прогресбара, а следом вставить в него DOM узлы, необходимые для нашей реализации. Допустим, мы и дальше используем div для задания хоста данному shadow root, тогда мы можем следующим образом создать новый div и приаттачить shadow root: <template div'); var shadowRoot = progressBar.attachShadow({mode: 'closed'}); shadowRoot.appendChild(document.getElementById('progress-bar-template').content.cloneNode(true)); progressBar.updateProgress = function (newPercentage) { shadowRoot.querySelector('.progress').setAttribute('aria-valuenow', newPercentage); shadowRoot.querySelector('.label').textContent = newPercentage + '%'; shadowRoot.querySelector('.bar').style.width = newPercentage + '%'; } return progressBar; } </script> Обратите внимание, что элемент style находится внутри template и будет склонирован в shadow root вместе с div'ами. Это ограничит область действия стилей этим самым shadow root. Точно так же стили снаружи не применяются к элементам внутри. Совет: во время дебага может оказаться полезным режим open shadow DOM, при котором shadow root будет доступен через свойство shadowRoot элемента-хоста. Например, {mode: DEBUG ? 'open' : 'closed'} Копозиция слотовВнимательный читатель к этому моменту наверняка задался вопросом: почему бы не сделать это средствами CSS и не лезть в DOM? Стилизация это концепция представления, зачем же мы добавляем новые элементы в DOM? На самом деле, первый публичный рабочий черновик CSS Scoping Module Level 1 определяет правило @scope как раз для этих целей. Зачем же понадобился ещё один механизм изолирования стилей? Хорошей причиной для имплементации послужило то, что элементы реализованные внутри компонента скрыты от внешних механизмов обхода узлов, таких как querySelectorAll и getElementsByTagName. Из-за того что по умолчанию узлы внутри shadow root не обнаруживаются этими API, пользователи компонент могут не задумываться о внутренней реализации каждого компонента. Каждый компонент представлен в виде непрозрачного элемента, детали реализации которого инкапсулированы внутри его shadow DOM. Имейте в виду, что shadow DOM никоим образом не заботится о cross-origin ограничениях как это делает элемент iframe. При необходимости другие сценарии смогут проникнуть внутрь shadow DOM. Однако, есть и другая причина по которой появился этот механизм – композиция. Допустим, у нас есть список контактов: <ul href="mailto:commit-queue@webkit.org">commit-queue@webkit.org</a> )<br> One Infinite Loop, Cupertino, CA 95014 </li> <li> Niwa, Ryosuke (<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a> )<br> Two Infinite Loop, Cupertino, CA 95014 </li> </ul> и хотим мы каждому пункту контактной информации из списка добавить красивостей при включённых скриптах: Вместо того чтобы копировать весь этот текст в наш собственный shadow DOM, мы могли бы следующим образом использовать именованные слоты для отрисовки текста в коде нашего shadow DOM не меняя его: <template DOMContentLoaded', function () { var contacts = document.getElementById('contacts').children; var template = document.getElementById('contact-template').content; for (var i = 0; i < contacts.length; i++) contacts[i].attachShadow({mode: 'closed'}).appendChild(template.cloneNode(true)); }); </script> Концептуально слоты – это незаполненные пробелы в shadow DOM, заполняемые потомками элемента-хоста. Каждый элемент назначается слоту с именем, определённым в атрибуте slot: <ul href="mailto:commit-queue@webkit.org">commit-queue@webkit.org</a> )<br> <span >Таким образом мы присоединяем к li наш shadow root, а каждый span с атрибутом slot назначается слоту с соответствующим именем внутри shadow DOM. Взглянем подробнее на шаблон shadow DOM: <b>Name</b>: <slot >В этом шаблоне имеется два слота с названиями email и address, а также слот с названием fullName, содержащий внутри себя два других слота firstName и lastName. Слот fullName пользуется техникой фолбека, когда firstName и lastName отображаются только в случае отсутствия узлов назначенных fullName. Несмотря на то, что в данном случае каждому слоту назначен ровно один узел, мы могли бы назначить множество элементов с одинаковым атрибутом slot одному и тому же слоту, тогда бы они отображались в том же порядке, в каком они расположены потомками хост-элемента. Можно также использовать безымянные стандартные слоты, их заполнят те потомки хоста, у которых не указан атрибут slot. Когда браузер рендерит этот компонент, содержимое li заменяется на shadow DOM, а слоты внутри него заменяются назначенными узлами так, будто на самом деле отображается следующий DOM: <ul href="mailto:commit-queue@webkit.org">commit-queue@webkit.org</a> <!--slot-content-end--> </slot><br> <b>Address</b>: <slot >Как видите, основанная на слотах композиция это мощный инструмент, позволяющий виджетам вставлять в страницу содержимое без клонирования и изменения DOM. С его помощью виджеты могут реагировать на изменения их потомков не прибегая к MutationObserver или каким-либо явным уведомлениям от сценариев. В сущности, композиция превращает DOM в связующий механизм коммуникации между компонентами. Стилизация хост-элементаЕсть ещё один момент, который стоит отметить в предыдущем примере – мистический псевдокласс :host: <template >Этот псевдокласс, как следует из его имени, применяется к хосту shadow DOM, в котором находится это правило. По умолчанию, авторские стили снаружи shadow DOM имеют более высокий приоритет в сравнении со стилями внутри shadow DOM. Это сделано чтобы внутри компонента можно было определить «стили по умолчанию», а пользователям компонента дать возможность их переопределять когда нужно. В дополнение, компонент может определить принципиально важные для его отображения стили (такие, например, как ширина или display) с ключевым словом !important. Любые !important правила внутри shadow DOM считаются более приоритетными тех !important, что объявлены снаружи. Дальнейшая работаМного работы ещё впереди относительно внедрения Веб Компонентов. Мы бы хотели позволить стилизировать слоты shadow DOM через стили соответствующих внешних узлов. Есть также пожелания научить компоненты встраиваться в тему документа, а также выставлять наружу стилизируемые части в виде псевдоэлементов CSS. В долгосрочной перспективе мы бы хотели увидеть императивный DOM API для манипуляции назначением слотов, мы уже давно предлагали это сделать. А ещё мы заинтересованы в дополнении shadow DOM произвольными (custom) элементами. Вкратце, custom elements API даёт авторам возможность ассоциировать классы JavaScript с конкретным именем элемента в документах HTML; отличный способ идеоматически назначать произвольное поведение и shadow DOM. К сожалению, на данный момент существует несколько противоречивых предложений о том как и когда создавать произвольные элементы. Чтобы помочь направить обсуждение в W3C мы планируем сделать прототип в WebKit. Для сборки пакетов и поставки Веб Компонентов мы работаем над модулями ES6. Как и Mozilla, мы верим что модули радикально изменят отношение авторов к структурированию их страниц. В конечном счёте мы хотели бы спроектировать API создания полностью изолированных веб компонент с подобными iframe политиками безопасности, основанными на shadow DOM и произвольных элементах. В заключение, хотелось бы отметить что мы действительно очень гордимся тем, что значительные возможности Веб Компонентов появляются в WebKit, мы будем и дальше писать о новых появляющихся возможностях. В случае если у вас остались какие-то вопросы обращайтесь напрямую ко мне, @WebKit или к Джону Дэвису.

источник картинки: southriverrestoration.com/wp-content/uploads/2015/04/Power-of-Communication-STOCK.jpg Как известно, качество открытых данных (в частности данных о госфинансах) часто оставляет желать лучшего. В некоторых случаях это не мешает их использовать, в других — требуются комментарии источников данных или дополнительные сведения. Источниками открытых данных в основном являются госорганы, при взаимодействии с которыми есть, как минимум, одна большая проблема — 30 дней на ответ. Не все программисты обладают достаточным терпением, да и для представителей коммерческих компаний такое ожидание неприемлемо. Но, даже если вы дождались ответа, радоваться приходиться далеко не всегда — иногда вы получаете ответы не на все заданные вопросы, иногда вам предлагают обратиться в другие госорганы, что требует дополнительного ожидания. Попробуем систематизировать, какие еще есть способы «достучаться» до госорганов по вопросам, связанным с их открытыми данными. Нулевой способ, доступный только для «избранных» — найти знакомого или знакомого знакомого в интересующем госоргане. Да, этот способ нельзя назвать официальным, но, к сожалению, он самый эффективный (могу предположить, что это связано с «менталитетом» или «традициями в госуправлении»). В некоторых случаях это единственный вариант относительно быстро получить интересующие данные или комментарии, поэтому нетворкинг и посещение мероприятий жизненно необходимы (как истинный интроверт пишу об этом с болью). Первый и самый традиционный способ, — это официальные обращения. Чаще всего их можно отправить через электронную форму на сайте или на официальную электронную почту (хорошо, что не нужно пользоваться Почтой России или приносить обращения лично). Несомненный плюс этого способа — это регулирование законом 59-ФЗ, согласно которому ответить вам обязаны. Минусы — ответ придется подождать месяц. Образцы обращений по запросу информации можно посмотреть на сайте ИРСИ, но основные правила просты: будьте вежливы и конкретны, полезным будет сослаться на нормативно-правовую базу. Пример 1. Обращение через электронную форму в Федеральное Казначейство. При использовании данных по госконтрактам аналитиками Инфокультуры было замечено, что в выборке по контрактам, где 'ИНН поставщика = ИНН Сбербанка' встречаются контракты с физ. лицами и компаниями, которые явно не относятся к Сбербанку. Не найдя объяснения этому явлению, был отправлен соответствующий запрос в Федеральное Казначейство, которое отвечает за данные портала ГосЗакупки. Ответ пришел через неделю (это очень быстро для госоргана), но он оказался бесполезным: обращение рассмотрено, персональную ответственность несет лицо, заполняющее документы от имени заказчика, в госзакупках реализован предупреждающий контроль. Что делать с ответственностью заказчика и почему предупреждающий контроль не работает осталось не ясным. Ответ ФК После беглого анализа данных выяснилось, что чаще всего неправильные данные указывают муниципальные организации (особенно детские сады), поэтому ошибки при заполнении документов можно списать на низкую ИТ-грамотность (имхо). Пример 2. Обращение через электронную почту в Муниципалитет Санкт-Петербурга. Это мой любимый запрос, потому что в нем госорган сделал все ошибки, которые только можно было сделать, а все эксперты, посвященные в проблему, считали, что муниципалитет прав. Проблема была в том, что в бюджете Дворцового муниципального образования использовался один и тот же код для обозначения двух разных муниципальных программ (что недопустимо согласно Бюджетного кодекса). Для меня этот вопрос был принципиален, потому что при анализе бюджетов Санкт-Петербурга мы брали за аксиому уникальность сочетания «код муниципальной программы» — «наименование муниципальной программы» и наличие данной ошибки влияло на обработку данных. Первое электронное письмо в Дворцовый осталось без ответа. Перезвонила я им через четыре месяца, так и не получив ответа. Ответившая на звонок девушка перестала дышать, когда услышала, что молчат они 4 месяца (а 59-ФЗ никто не отменял). Она перевела меня на секретаря, тот на бухгалтера, а по версии «бухгалтера» на сайте «были ошибочные данные, в ее данных все в порядке и они опубликуют правильные файлы на сайте». Конечно же они ничего не опубликовали. И, после повторного звонка, заявили, что у них все в порядке и они отправят разъяснения по почте, потому что я не понимаю бюджетную классификацию. Разъяснения Дворцового МО Муниципальная программа (согласно Бюджетного Кодекса) кодируется 7 знаками. В ответе говорится, что у Дворцового МО она кодируется 11 знаками (включая код раздела и подраздела). Чтобы доказать наличие ошибки, потребовалось обратиться в Комитет финансов СПб, после пересылки ответа которого Дворцовый признал ошибку (дополнительно проконсультировавшись с Комитетом финансов СПб) и пообещал ее исправить в 2016 году. Попутно они согласились возобновить публикацию своего бюджета в XLS (считаю это дополнительным бонусом). Интересно, что в Комитете финансов СПб мнения разделились и параллельно с официальным ответом, согласно которого коды повторяться не могут, я получила неофициальный, согласно которого коды повторятся могут. Выводов два. Первый: в бюджетах муниципалитетов действительно много ошибок (и опечаток). Второй: есть трудности с правильным пониманием бюджетной классификации муниципальными органами. Пример 3. Запрос данных о муниципальных бюджетах Ленобласти. На примере Санкт-Петербурга выяснилось, что бюджеты 100 муниципалитетов собирать по их официальным сайтам очень долго и утомительно. Появилось предположение, что их можно запросить у регионального комитета финансов. Предположение оказалось провальным: муниципальная власть не является третьим уровнем власти и не подчиняется региональной, поэтому муниципальные данные есть только у муниципалитетов (запрашивать их у регионов и Минфина бесполезно). Но мне показался необычным процесс коммуникаций с Ленинградской областью. Все обращения отправляются с сайта Ленобласти (а не напрямую с сайта интересующего госоргана) и попадают в «центр обращений», из которого их отправляют в нужные госорганы. Весь следующий день до меня дозванивалась представительница Ленобласти, которой для регистрации обращения требовалось узнать, в каком городе я живу (понятия не имею, зачем это нужно и почему этого вопроса не было в электронной форме), но после этого ответ был получен за 4 (!) дня. На встрече Минфина с разработчиками, которая прошла 16 июня, выяснилось, что при наличии «проблем» с муниципалитетами обращаться нужно или в Генеральную прокуратуру (или писать письмо В.В. Путину). Предвкушаю, как и тот и другой адресаты будут рады получать кучу писем от Инфокультуры с такими важными в масштабах государства проблемами, как опечатки в муниципальных бюджетах :). Второй способ коммуникаций — написать на почту, предназначенную для вопросов по открытым данным (например, opendata@minfin.ru у Минфина), администратору или технической поддержке сайта, оставить вопрос на специальном форуме (например, форум Казначейства на budget.gov.ru). В этом случае есть шанс, что ответ вы получите быстрее и ваш вопрос попадет напрямую к отвечающим за открытые данные людям, а при использовании форумов ответ будет доступен не только вам, но и всем заинтересованным. Правда, такие письма не всегда приравнены к официальным обращениям, и вероятность не получить никакого ответа все же есть. Третий способ, набирающий особенную популярность в июне, — участие в хакатонах и конкурсах. один из хакатонов пройдет на этих выходных в Петербурге и будет посвящен финансовым данным, другой — в Москве в июле, ну а всем известный конкурс Минфина BudgetApps в представлении не нуждается. Госорганы не только начинают участвовать в подобных мероприятиях, но и сами их организовывают. А это значит, что вы не только можете получить прямой доступ к представителям госорганов на самом мероприятии (поверьте, отвертеться от неожиданных вопросов, заданных в живую намного сложнее, чем придумать отписку за месяц), но и получить дополнительный канал связи (форму для запросов или специальную почту). Ценность этого способ в том, что не только вам нужны госорганы, но и они нуждаются в вас — как минимум, отчетность и пиар никто не отменял, а в идеальном случае это сопровождается еще и искренней заинтересованностью госорганов в получении содержательного результата. И, даже если на мероприятии представители госорганов не присутствуют, вы всегда можете обратиться к менторам и экспертам, которые могут связать вас с ними или что-то подсказать. Есть еще один, эксклюзивный, способ общения с Минфином — это встречи с разработчиками, которые проходят второй год (не уверена, что о них всегда можно узнать заранее, но будем считать, что это так). Одна из первых встреч прошла год назад, самая последняя — на прошлой неделе. И, по-моему, они начинают “работать” — докладов больше и они содержательнее, госорганы немного вникли в предметную область (открытые данные) и начинают понимать, о чем говорят, представители коммерческих компаний готовят содержательные доклады. Единственный минус — “информационное сообщение” Минфина об этих встречах пока страдает: встреча длилась два часа, докладов было много, ответы на вопросы звучали интересные, а информационное сообщение только о 20-минутном докладе Минфина (да еще и написано так, что даже заинтересованным в открытых данных читать скучно). Если ни один из описанных способов не помог — не отчаивайтесь, обращайтесь не к первоисточнику, а к сообществу, экспертам и проектам. Например, обо всем, что относится к госконтрактам и госфинансам (да и в целом к открытым данным), вы можете спросить у нас ;-).
Дайджест Университета ИТМО: #2 Научные разработки, видеосюжеты об ученых и ближайшие мероприятия

Тим Ромеро основатель Vanguard K.K. в своем блоге на Медиум написал занимательный пост, который мы решили перевести. Я сделал то, чего ни один основатель стартапа, казалось бы, никогда не сделает. Я сдался. Это даже не было одним из тех славных случаев, когда люди учатся на своих ошибках и идут вперед. За спиной было семь месяцев тяжелой работы, мы проверили идею, подготовили абсолютно все и через две недели деньги должны были быть у нас на руках. У нас была хорошая команда, блестящие отзывы бета-пользователей и предварительный договор с инвесторами на 250 000 долларов. Но я свернул дело. Моя команда и большинство инвесторов в ярости, но я уверен, что поступил правильно. По крайней мере, думаю, что уверен. В этом деле была одна неустранимая, с моей точки зрения, проблема. Мои инвесторы и члены команды хотели, чтобы мы взяли средства и придумали решение, прежде чем деньги закончатся. До этого я основывал четыре компании, неоднократно разорялся и уходил, так что я понимаю, что без этого никуда, но на сей раз я не мог снова на это пойти. Эта статья писалась отчасти как объяснение для заинтересованных лиц, отчасти для самоуспокоения и отчасти для других основателей и инвесторов, чтобы узнать, как бы они поступили в такой ситуации. Я начал работать над ContractBeast в октябре прошлого года. Мы предлагали управление жизненным циклом контрактов на основе SaaS. Если вы не работали в крупных ИТ-компаниях, вы, возможно, не слышали об управлении жизненным циклом контрактов, или CLM (Contract Lifecycle Management). Вкратце, CLM занимается вопросами создания, согласования, исполнения и хранения контрактов, как на бумаге, так и в электронной форме, со строгим контролем доступа. Сюда также входят такие услуги как уведомление заказчика об истечении срока контрактов или их автоматическом обновлении и предоставление списка ответственных лиц. CLM – очень фрагментированный сектор рынка с объемом средств 7.6 миллиардов долларов, на котором 80 авторитетных компаний борются за свою долю – если не считать десятки появившихся за последние годы стартапов, занимающихся электронными подписями. Почти все эти компании работают в сфере предпринимательства, где преобладают длинные циклы купли-продажи по стратегии “снизу вверх” и есть возможность получать доход с консультирования и адаптации. Начнем с того, что только рынок крупного бизнеса тяготеет к фрагментации. Рынок среднего и малого бизнеса очень мало обслуживается, а на корпоративном рынке цены неоправданно высокие. ContractBeast – SaaS-продукт с невысокой стоимостью без необходимости консультирования. Мы планировали начать с рынка среднего бизнеса, а затем уйти в корпоративный. Как создавался Beast Целевая аудитория позитивно отозвалась о наших тестовых моделях и мы получили ценный опыт от этих интервью, и многие с энтузиазмом спрашивали, когда появится готовая версия. Я был на верном пути. Следующие несколько месяцев по вечерам и на выходных я разрабатывал минимальный жизнеспособный продукт и получал отзывы о компонентах по мере их появления. Я ушел с работы в январе и теперь мог уделять ContractBeast более 70 часов в неделю. Другие члены команды остались на своих рабочих местах. Да и к лучшему. Это упростило принятие моего последнего решения. Мы выпустили бета-версию в начале марта, и вроде бы всё было отлично. Около 35% зарегистрировавшихся в системе продолжили ее использовать как минимум три раза в неделю. UI нуждался в доработке, но наши пользователи с энтузиазмом обсуждали, как ContractBeast сэкономит их время и нервы. Команда ликовала. Потенциальные инвесторы ждали с нетерпением. Но что-то было не так. Сначала все шло как обычно, но что-то не давало мне покоя. Несмотря на все похвалы, наши пользователи использовали ContractBeast для создания лишь малой части своих контрактов. Следующие две недели я приходил к нашим пользователям, смотрел, как они работают, спрашивал, как они собираются работать с продуктом. Пытаясь узнать, почему они не используют ContractBeast для создания всех контрактов, я получил множество запросов опций. Говорить с пользователями об опциях непросто. Нередко они подают полезные и ценные идеи. Иногда пользователь дает такое понимание ситуации, которое меняет наш взгляд на продукт. Но по большей части, им на самом деле не нужны те опции, о которых они просят. Когда пользователь недоволен и сам не может объяснить, почему, он часто говорит о целом ряде сторонних, незначительных опций, которые ему нужны. Мы получили много обращений с просьбой высылать уведомления в мессенджеры, использовать искусственный интеллект для анализа контрактов, расширить возможности поиска. Я не говорю, что это плохие идеи, но они не объясняют, почему люди не использовали ContractBeast активнее. Я мог бы написать отдельную статью о том, как отличить эти излишние запросы от дельных. Ваши клиенты хотят, как лучше, но создание всех этих функций не поможет удовлетворить их в ближайшем будущем. И я продолжал в больших количествах получать такие сторонние запросы. Я не мог спать. Мои пользователи говорили, что им нравится продукт, и они собираются работать с ним в долгосрочной перспективе. Но на деле они не очень-то его использовали, и я не могу понять, почему. Потягивая кофе без кофеина прохладным майским утром в 5:00, я перечитывал сорок страниц записей, отзывов пользователей и критики. И наконец, меня осенило. ContractBeast позволял достичь высокой точности и эффективности, но только после месяцев использования. Он не давал значительных улучшений сразу. Я боролся с человеческой природой – и я проигрывал. Все клянутся, что начнут правильно питаться и делать зарядку, но единицы это делают. Все согласны, что им нужно с наименьшими затратами обеспечить свою фининсовую безопасность в будущем, но единицы это сделают. Наши пользователи говорили, что будут использовать ContractBeast, чтобы достичь этого долгосрочного результата, но единицы это делали. Я посмотрел на контракты, которые создавали люди, и обнаружил, что в большинстве случаев это были контракты, в которых какая-то опция давала ощутимый мгновенный результат. Как правило, проверка и скрепление договора. Проклятая природа человека… Попытки спасти Beast У этой проблемы было два решения: либо изменить стратегию выхода на рынок, либо изменить продукт. Период с индивидуального внедрения и самообслуживания на стратегию “сверху вниз” и метод консультативных продаж были очевидным решением проблемы. Отдельные пользователи вряд ли пойдут на краткосрочные изменения для достижения долгосрочных результатов, а вот ИТ-директор без проблем поможет им сделать это. Это его работа. К сожалению, продажи снизу вверх гораздо затратнее контент-маркетинга и SEO. Расчеты показали, что нам придется поднять цены до уровня, который вытолкнет нас из рынка среднего бизнеса в зону конкуренции с более авторитетными и хорошо финансируемыми компаниями. Поскольку у нас не было преимущества в этом рыночном сегменте, идея была обречена на провал. Остался лишь один вариант: найти способ удовлетворить покупателей в краткосрочной перспективе. Мы начали искать, что может дать мгновенные результаты. В среднем и малом бизнесе контрактный менеджмент никогда не был проблемой, требующей срочного решения. Практически единственным способом превратить потенциальных пользователей в реальных покупателей было заставить их активно использовать пробную версию ContractBeast. Мы просмотрели все запросы новых функций от наших пользователей. Некоторые из них были отличными предложениями, но ни один не касался главного вопроса: что даст заметный, устойчивый и мгновенный результат? Внедрение этих функций было бы бессмысленным. Неделями мы проводили мозговой штурм, выдвигались десятки предложений, и всё было не то. Ни одного верного способа мгновенно дать нашим пользователям то, чего они подсознательно так жаждали. Инвесторы уже были готовы выделить средства, члены команды были готовы уйти со старой работы, но я не видел никаких перспектив и поэтому решил остановить проект. Как я похоронил Beast Члены команды и некоторые инвесторы настаивали на том, чтобы взять средства и постараться разработать решение проблемы до того, как эти средства закончатся. Таким и должен быть ход игры, и я понимаю, почему все, кто участвовал в проекте, недовольны тем, что я просто поджал хвост и убежал. Может быть, мы бы и нашли решение до истощения фондов, но недели мозгового штурма не дали никаких результатов. Одно дело, если бы нам приходилось выбирать из нескольких вариантов или если бы мы работали над устранением отдельных недостатков, но у нас не было ничего. Я не из тех, кто боится рисковать, но я просчитываю соотношение риска и дохода. Как инвестор, я бы, возможно, посоветовал себе взять деньги и попытаться. Но расчет риска и дохода для инвесторов и основателей отличается. Я просчитывал, стоила ли эта авантюра еще одного года работы по 70+ часов в неделю. Мне нужен больший уровень уверенности, чем инвесторам, потому что время для меня дороже, чем деньги для них.Инвесторы ставят на кон деньги, вкладываясь в компании, а у меня только одна жизнь. Прощание с Beast Через несколько недель, когда прошел первый шок, другие участники проекта, хоть они и были еще немного разочарованы, согласились, что закрыть проект было верным решением. Я тоже перестал сомневаться в правильности такого решения, пока писал эту статью. Не знаю, были ли вы в такой ситуации, но если были, мне было бы интересно узнать, как вы с ней справились. Всем понятно, что лучше вовремя остановиться и избежать лишних убытков, но принять такое решение невероятно сложно. И все же иногда лучше отказаться от риска.

Поговорим о тренировке. Вместе с криптолокерами в наш уютный ландшафт угроз пришли казалось бы давно забытые трюки: от «албанского вируса» (набор для самостоятельной зашифровки данных) до макросов в офисных документах. По меркам тех угроз, про которые действительно интересно читать, это прошлый век и детский сад, но вот проблема — работают ведь. В случае макросов от пользователей требуется сделать пару лишних кликов, в процессе выводятся предупреждения (опасно!), но нет, все кликается, загружается и приводит к реальным убыткам и потере данных, хорошо если только на одном компьютере. По нашим данным, число криптоатак на пользователей за последние два года выросло в пять раз — и этот тот случай, когда количество рано или поздно переходит в качество. Подавляющее большинство криптолокеров, а особенно такие трояны начального уровня, по-прежнему без проблем блокируются стандартным защитным софтом. Увы, это не исключает заражение полностью — и дело не в том, что стопроцентной защиты не бывает. Недавно я ссылался на пример, когда к неплохо защищенной инфраструктуре подключается внешний фрилансер с ноутбуком без антивируса и устраивает локальный армагеддон. Недавно к арсеналу древних трюков добавился еще один. Вместо макросов в офисные документы внедряют ссылки на внешние объекты с помощью технологии OLE (новость, исследование Microsoft). В документе этот хитрый маневр выглядит примерно как на картинке. В одном из случаев использовалась довольно топорная социнженерия: «Нажмите, чтобы разблокировать этот контент и доказать, что вы не робот». В Ворде такая конструкция выглядит чрезвычайно подозрительно, но ведь работает. И что с этим делать? Все выпуски дайджеста доступны по тегу. В случае с обычными пользователями понятно что делать — антивирус надо ставить. В случае компаний все сложнее, выше я уже привел пример, почему не всегда получается заблокировать все и везде. Сотрудников надо обучать. Желательно, чтобы тренинги по тому, что мы называем security awareness, отличались от росписи в журнале за инструктаж на случай пожара. Обучение должно быть регулярным, цели его должны быть понятны всем — именно поэтому мои коллеги, отвечающие за тренинги, говорят, что надо обязательно включать в программу не только обычных сотрудников, но и начальство, вплоть до топ-менеджеров. С точки зрения технаря это решение возможно выглядит немного странным, ну а куда деваться? Одним из качественных изменений в индустрии ИБ является именно расширение понятия безопасности за пределы борьбы хорошего кода с плохим. Безопасность — это люди, их запрограммировать не получится, и гневным циркуляром проблему не решить. Но пробовать надо: не будучи алгоритмизируемым решением, тренинги дают вполне измеряемую эффективность. Неделя патчей: Windows, Wordpress, libarchive Обнаружение уязвимостей в софте и выпуск патчей — это такой регулярный элемент новостного фона по теме безопасности. Настолько привычный, что в список самых посещаемых такие новости выбиваются нечасто: в моем еженедельном сериале это происходит примерно раз в квартал. Вот и настал такой момент: на повестке дня сразу три важных патча. В Microsoft залатали уязвимость в протоколе Web Proxy Auto Discovery (новость, бюллетень MS). И Microsoft, и первооткрыватель, исследователь из китайской компании Tencent, много деталей не раскрывают. В схеме работы протокола обнаружили возможность отката к уязвимому «процессу обнаружения прокси-сервера», конкретно эксплуатируется «предсказуемость идентификаторов транзакций при работе с Netbios». В списке подверженных — все версии Windows, начиная с 7, но по факту дыра присутствует даже в Windows 95, и, естественно, в неподдерживаемой более XP. Возможно причиной малого количества деталей является универсальность атаки. По словам исследователя, эксплойт может прилететь и в виде URL в браузере, и в виде вредоносного офисного документа, и даже на флешке (например с помощью вредоносного шортката). Дальнейшее развитие атаки нельзя назвать простым делом, но в итоге появляется возможность перехвата трафика или подмены доверенных сетевых устройств. Исследователи из Cisco нашли три уязвимости в опенсорсной библиотеке libarchive (новость, исследование). В случае с открытым софтом важнее даже не характер уязвимости, а понимание — кто подвержен. В этом может помочь список зависимого софта на сайте библиотеки. Все три уязвимости могут эксплуатироваться с помощью подготовленного архива определенного формата, конкретно подвержены 7-Zip и RAR. Кроме того, теоретически можно эксплуатировать уязвимость, когда библиотека работает с данными mtree, штатной утилиты в FreeBSD. Все три уязвимости позволяют выполнять произвольный код. Наконец, очередной апдейт Wordpress до версии 4.5.3 закрывает 24 уязвимости (новость, анонс Wordpress). Большая часть уязвимостей позволяет получить контроль над веб-сайтом. Дополнительно были исправлены 17 багов — причем все относительно свежие, они были «добавлены» в последних трех релизах открытой CMS. Что еще произошло: Проект Let's Encrypt сообщает о выпуске пятимиллионного бесплатного сертификата HTTPS. Одновременно с этим выяснилось, что компания Comodo, продающая SSL за деньги, зачем-то пытается зарегистрировать на себя торговую марку Let's Encrypt в США. Фу таким быть. Индийскую рекламную фирму inMobi, зарабатывающую в том числе на баннерах в мобильных приложениях, оштрафовали в США на почти миллион долларов за отслеживание пользователей без их ведома. Рекламная сеть этой компании предположительно «накрывает» больше миллиарда устройств. Древности: «Tired-1740» Резидентный опасный вирус, стандартно записывается в COM-, EXE- и OVL-файлы при их загрузке в память для выполнения. Периодически расшифровывает и выводит на экран фразу: «I think you're too tired to the bone. You'd better go home», а затем перезагружает компьютер. Перехватывает int 21h. Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 85. Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

1. Привет. На хабре подозрительно мало информации про Open Build Service (далее OBS) и прочие платформы. А про свежесть имеющегося и говорить не хочется. Недавно был релиз версии 2.7, пришли долгожданные изменения. Но, для истории, хочу немного рассказать об одном варианте использования 2.6 (релиз — февраль 2015 года). Пример для материала навеян недавней потребностью. Итак, собирем php-ffmpeg на базе ffmpeg 3.0 для Centos (7, и даже 6*!). 2. Схема Все необходимые команды я долгое время выполнял методом copy-paste из своей wiki. Абсолютно все выполняется в консоли, в т.ч. через API OBS. Сейчас весь процесс разбит на 4 этапа: это все что надо будет запустить в консольcd ~ && git clone https://github.com/BOPOHA/obs-fast-c7ffmpeg && obs-fast-c7ffmpeg bash -x obs-fast-c7ffmpeg-n1-prepare.sh # при успешном окончании сервер перезагрузится cd ~/obs-fast-c7ffmpeg bash -x obs-fast-c7ffmpeg-n2-mkvps.sh bash -x obs-fast-c7ffmpeg-n3-buildtargets.sh bash -x obs-fast-c7ffmpeg-n4-buildpkgs.sh n1 — под готавливаем хост для работы, устанавливаем средства виртуализации, ребут. n2 — сетапаем VPS на базе подготовленного .qcow2 образа n3 — настраиваем OBS: добавляем свои центосы, создаем целевой проект n4 — отправляем тарболы и спеки на сборку Все необходимое для сброки доступно в github. Используемое железо: Xeon E3-1230 3.2 GHz / 8GB / 2x500GB / 100Mbs / CentOS 7.x Затраченное время ~2 часа (40мин на rsync rpm-ок, и чуть более часа на сам процесс сборки ). Далее, по каждому из скриптов, я отмечу наиболее важные, на мой взгляд, моменты. n1-prepare.sh Тут добавляем в GRUB_CMDLINE_LINUX некоторые опции, для повышения производительности. Отдельно стоит > Тут в общем-то больше ничего интересного, устанавливаем сторонний репозиторий openSUSE:Tools для работы через API, и пакеты libvirt/kvm. n2-mkvps.sh Все необходимые данные для настройки окружения были почерпнуты отсюда: openSUSE:Build_Service_private_installation. obs-server_os.rawwget http://download.opensuse.org/repositories/OBS:/Ser...images/obs-server.x86_64.qcow2 qemu-img create -f raw -o > Тут берем подготовленный образ. Он по умолчанию не имеет достаточно свободного места для нормальной работы, поэтому производим изменения размера, и небольшое изменения в ФС: добавление нескольких команд в автозагрузку генерация ssh-key на хосте и копирование pub-key в OBS. копирвоание скрипта для обновления rpm-ок. obs-server_lvm.rawqemu-img create -f raw -o > Как описано в Build_Service_private_installation, этот кусок кода создает второй диск, с LVM разделом и необходимой разметкой. При загрузке, система его опознает и самостоятельно продолжит настройку. virt-install --name OBS_servervirt-install \ --name OBS_server \ --ram 7168 --vcpus 4 \ --disk > sleep 180 — ждем первую загрузку OBS и инициализацию LVM, после чего ребут OBS. sleep 60 — после этого считаем что OBS готова к работе поиск IP OBSVPS_MAC=`virsh dumpxml OBS_server | grep -o '..:..:..:..:..:..'` s|^.*(\(.*\)).*$|\1|'` touch /etc/hosts /root/.ssh/known_hosts sed -i "/linux/d; /$VPS_IP/d;" /etc/hosts /root/.ssh/known_hosts echo "$VPS_IP linux" >> /etc/hosts ssh linux > Тут по mac-адресу ищем IP OBS, и прописывае его hosts. Следует отметить, что параметры размера диска 128G, и количества vcpus — взаимосвязаны. По умолчанию, количество веркеров равно количеству vcpu. Если вам потребуется собрать большой проект, то 5GB может не хватить, потребуется либо увеличить рамер раздела, либо уменьшить количество ядер, либо изменить соотв. параметр в /etc/sysconfig/obs-server. Ниже пример: lsblk OBS n3-buildtargets.sh скрипт#!/bin/bash set -e export s Home Project</title> <description></description> <person /> <person /> </project> EOF osc meta prj $REPO_NAME -F - << EOF <project /> <repository > На первый взгляд и тут все просто, но самом деле, подобные манипуляции нигде явно в документации не освещены. osc meta prj -F - centos7 << EOF Регистрируем подключаемый репозиторий centos7. osc meta prj home:$ACC -F - << EOF Создаем "Home Project" home:Admin. osc meta prj $REPO_NAME -F - << EOF Создаем c суб-проект home:Admin:obs-fast-c7ffmpeg. А самое сложное было найти команду osc meta prjconf -F ___env/centos7.conf centos7. Это билд-конфиг соответствующей ОС. Файл centos7.conf можно накурлить из комьюнити проекта одним из приведенных способов: osc -A https://api.opensuse.org meta prjconf CentOS:CentOS-7 > centos7.conf curl https://api.opensuse.org/public/source/CentOS:CentOS-7/_config > centos7.conf n4-buildpkgs.sh Последний этап, создание пакетов, реализуется функцией: function pushfunction push { cd $TMP_DIR > Функция регистрирует в OBS пакет, переходит в локальную папку с проектом (/home/tmp/home:Admin:obs-fast-c7ffmpeg/), обновляет папку с пакетом, синхронизирует данные с OBS и делает комит. Сразу после этого пакет начинает собираться одним из свободных веркеров. Для сборки php-ffmpeg в Centos7 потребуется совсем не много: push lame push ocl-icd push x265 push x264 push xvidcore push opencl-headers push ffmpeg push php-ffmpeg процесс сборки можно контролировать по разному Откуда взять материал для сборки? Наиболее простой способ — воспользоваться готовым из src.rpm fedora (поиск тут https://www.rpmfind.net/ ). список использованых src.rpmftp://195.220.108.108/linux/fedora-secondary/development/rawhide/source/SRPMS/o/ocl-icd-2.2.8-2.git20151217.0122332.fc24.src.rpm ftp://195.220.108.108/linux/fedora-secondary/devel...ncl-headers-1.2-9.fc24.src.rpm (centos 6) ftp://195.220.108.108/linux/sourceforge/u/un/unite...rpm/lame-3.99.5-5.fc24.src.rpm ftp://195.220.108.108/linux/sourceforge/u/un/unite...0160420git3b70645.fc24.src.rpm ftp://195.220.108.108/linux/sourceforge/u/un/unite...0160221git40ba1eb.fc24.src.rpm ftp://195.220.108.108/linux/sourceforge/u/un/unite.../xvidcore-1.3.4-1.fc24.src.rpm ftp://195.220.108.108/linux/sourceforge/u/un/unite...pm/ffmpeg-3.0.1-2.fc24.src.rpm В некоторых случаях, потребовались небольшие правки спеков, в таком случае оригинальный файл имеет расширение .orig. *Centos 6 Система хорошая, надежная ) но, вот беда, пакетная база устарела для сборки многих пакетов актуальных версий. Для успешной сборки ffmpeg, потребуется дополнительно собрать ocl-icd-devel, soxr-devel, и их зависимости. Но самое сложное, это обновить несколько важных системных пакетов: autoconf, automake, m4,… а они взаимозависимые. Так как эта задача одноразовая, и мы ленивые, то воспользуемся https://pkgs.org/ для поиска необходимых пакетов. Добавим найденное в репу OBS и перезапустим сервис: c6hackcd /srv/obs/build/centos6/epel/x86_64/:full/ wget http://springdale.math.ias.edu/data/puias/computat...151217.0122332.sdl6.x86_64.rpm wget http://springdale.math.ias.edu/data/puias/computat...151217.0122332.sdl6.x86_64.rpm wget http://springdale.math.ias.edu/data/puias/6/x86_64...-devel-0.1.1-3.sdl6.x86_64.rpm wget http://springdale.math.ias.edu/data/puias/6/x86_64...s/soxr-0.1.1-3.sdl6.x86_64.rpm rcobsscheduler restart obs_admin --deep-check-project centos6 x86_64 Как использовать Для начала, необходимо пробросить порты. На 443 висит веб-морда, на 82 — репозиторий. Наиболее простым и гибким вариантом будет установка nginx и добавление двух строк в дефолтный конфиг: # grep location\ / -A3 /etc/nginx/nginx.conf location / { proxy_pass http://192.168.122.218:82/; proxy_redirect off; } # Далее необходимо создать файл /etc/yum.repos.d/obs-fast-c7ffmpeg.repo примерно следующего содержания: [obs-ffmpeg-c7] name = obs-ffmpeg-c7 baseurl = http://123.123.123.123/home:/Admin:/obs-fast-c7ffmpeg/CentOS_7/ gpgkey = http://123.123.123.123/home:/Admin:/obs-fast-c7ffm...ntOS_7/repodata/repomd.xml.key gpgcheck = 1 На последок. Для тех, кому требуется собирать пакеты без затрат, может понравится этот ресурс https://build.opensuse.org/. Среди минусов: устаревшая пакетная база ОС. Например при актуальной Centos 6.6, сборка проходила на базе Centos 6.3 (а там openssl очень старый и т.д.) нет возможности подключения сторонних репозиториев (тот же epel-release) множественные ограничение по пакетам https://en.opensuse.org/openSUSE:Build_Service_application_blacklist Полезные ссылки: https://ru.opensuse.org/openSUSE:OSC https://en.opensuse.org/openSUSE:Build_Service_private_installation https://en.opensuse.org/openSUSE:Build_Service_private_instance_software_live_cycle https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks https://en.opensuse.org/openSUSE:Build_Service_adding_build_targets https://en.opensuse.org/openSUSE:Build_Service_Concept_CrossDevelopment