Русский
Русский
English
Статистика
Реклама

Open source

Перевод Опенсорс и эксперименты с виртуальным конструктором LEGO

28.06.2020 18:15:43 | Автор: admin
Моё детство примерно на 20% состояло из Dungeons & Dragons (D&D) и на 80% из LEGO. Эти два занятия очень сильно пересекались. Мне, по разным причинам, не разрешали всё время играть в D&D. Но я, привлекая на помощь воображение, и достигнув в этом деле успехов, достойных плута 15 уровня, понял, что создание персонажей AD&D игрой не считается. Воссоздание вселенной DragonLance средствами LEGO очень хорошо помогало мне быть ближе к игре, которая мне очень нравилась.

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



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

CAD для LEGO


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

А вот системы автоматизированного проектирования (Computer-Aided Design, CAD), это уже нечто другое. CAD-приложения пришли на смену обычным чертежам. В них создают спецификации, иллюстрирующие то, как нечто может быть создано в реальном мире. От этих программ ждут точности и реализма.

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

Для того чтобы построить виртуальную модель LEGO, нужны две вещи:

  • Виртуальные детали LEGO.
  • CAD-приложение.

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

Виртуальные детали LEGO


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

Установка набора деталей


Виртуальные детали очень похожи на изображения, которые используются на сайтах, или на шрифты, применяемые на компьютере. Собственно говоря, соответствующие файлы можно хранить где угодно. Главное, чтобы приложение, в котором планируется работать с деталями, знало о том, где эти файлы находятся. В Linux LDraw-файлы обычно размещают в папке /usr/share/LDRAW. В Windows это обычно C:\Users\Public\Documents\LDraw.

LDraw даёт в наше распоряжение лишь спецификации для каждой детали. Вот, например, как выглядит код описания кубика 1x1:

0 ~Brick 1 x 1 without Front Face0 Name: s\3005s01.dat0 Author: John Riley [jriley]0 !LDRAW_ORG Subpart UPDATE 2004-010 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt0 BFC CERTIFY CCW0 BFC INVERTNEXT1 16 0 24 0 0 0 6 0 -20 0 -6 0 0 box5.dat4 16 10 24 -10 6 24 -6 6 24 6 10 24 104 16 10 24 10 6 24 6 -6 24 6 -10 24 104 16 -10 24 10 -6 24 6 -6 24 -6 -10 24 -104 16 -10 24 -10 -6 24 -6 6 24 -6 10 24 -101 16 0 24 0 10 0 0 0 -24 0 0 0 10 box4t.dat1 16 0 0 0 0 0 1 0 1 0 -1 0 0 stud.dat0

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

Приложение LDView для визуализации деталей


LDView это среда для 3D-рендеринга, напоминающая POV-Ray или Cycles из Blender. Это приложение создано специально для рендеринга .ldr-файлов, то есть CAD-файлов, содержащих данные в формате LDraw.

Если вы работаете на Linux, то, возможно, вы найдёте LDView в своём репозитории ПО. Если в репозитории этой программы не окажется вы можете скачать установщик с сайта проекта. Если вы пользуетесь macOS или Windows, то вам, опять же, нужно будет воспользоваться сайтом LDView.

Просмотр отдельной детали


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

Сначала откройте ваш любимый текстовый редактор. Это может быть любая программа. Главное чтобы она могла сохранять документы в виде обычного текста. Некоторые текстовые редакторы, в стремлении оказать пользователям добрую услугу, пытаются сохранять текстовые материалы в файлах, в которых, помимо текстов, есть ещё масса служебной информации (вроде .rtf и .doc). Существует множество хороших кросс-платформенных текстовых редакторов. Я, для наших дел, могу порекомендовать довольно-таки минималистичный редактор Geany.

Создадим новый файл с именем 1brick.ldr и введём в него следующий текст:

0 Name: 1brick.ldr0 Author: Seth Kenlon0 clr x y z a b c d e f  g h i <file>1  1 0 0 0 0 0 1 0 1 0 -1 0 0 3001.dat

А теперь взглянем на наше скромное творение:

$ LDView 1brick.ldr


Кубик LEGO

Только что вы создали простой CAD-файл, описывающий один кубик (а именно модель номер 3001), цветовой индекс которого равняется 1 (это синий цвет), расположенный в позиции (0, 0, 0) по осям X, Y и Z. Поворот кубика регулируется с использованием средств матричного преобразования. Их применение, надо признать, не относится к простым математическим вычислениям. Правда, при конструировании LEGO-моделей произвольное вращение деталей требуется сравнительно редко, так как большинство деталей стыкуются друг с другом с использованием шипов.

Любая строка в файле, начинающаяся с 0, содержит либо комментарий, либо метаданные. Строка, начинающаяся с 1, содержит описание детали.

Вы можете попрактиковаться в перемещении и вращении деталей, внося изменения в свой CAD-файл. Обычный кубик имеет в высоту 24 LDU (LDraw Units). Это значит, что ставить детали друг на друга можно, меняя их координату Y с шагом в 24 единицы. Поворачивать детали можно, выполняя матричные преобразования.

Взгляните на этот код:

0 Name: 1brick.ldr0 Author: Seth Kenlon0 clr x y z a b c d e f  g h i file1  1 0 0 0 0 0 1 0 1 0 -1 0 0 3001.dat1  2 0 24 0 -1 0 0 0 1 0  0 0 -1 3001.dat

Вот результат его визуализации.


Два кубика

Конечно, перемещать детали можно вдоль любой из трёх осей. В спецификации LDraw сказано, что кубик 1x1 имеет 20 LDU в ширину и 20 LDU в длину. А это значит, что расставлять такие кубики вдоль оси X можно, меняя их позиции с шагом в 20 LDU.

0 Name: 1brick.ldr0 Author: Seth Kenlon0 clr x y z a b c d e f  g h i file1  1 0 0 0 0 0 1 0 1 0 -1 0 0 3001.dat1  2 0 24 0 -1 0 0 0 1 0  0 0 -1 3001.dat


Ещё два кубика

Порядок сборки модели


Чаще всего формат LDraw используется для того чтобы продемонстрировать порядок сборки модели. А это значит, что нужно описать последовательность шагов сборки. В LDraw это делается с использованием метакоманды STEP.

Для того чтобы испытать эту метакоманду, добавьте в свой файл, между описаниями деталей, следующее:

0 STEP

Готовый файл будет выглядеть так:

0 Name: 1brick.ldr0 Author: Seth Kenlon0 clr x y z a b c d e f  g h i file1  1 0 0 0 0 0 1 0 1 0 -1 0 0 3001.dat0 STEP1  2 0 24 0 -1 0 0 0 1 0  0 0 -1 3001.dat

Теперь в вашем проекте описано два шага. На первом выводится первый кубик, на втором второй. Можно пошагово просматривать .ldr-файлы, пользуясь клавишами-стрелками в верхней панели инструментов LDView, находящимися около подписи Steps.


Панель инструментов для пошаговой визуализации моделей

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

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

Выяснение кодов деталей


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

Если учесть то, что в LEGO имеется более 11000 уникальных деталей, искать цифровые детали так же сложно, как и обычные. У каждой официальной детали LEGO есть собственный код. Например, тот кубик 2x4, который мы использовали в примере, имеет код 3001. Если вам известен код детали, вы можете просто использовать его в CAD-файле, и соответствующая деталь появится в вашей модели.

В дистрибутиве LDraw имеется файл parts.lst, в котором, с помощью grep, можно найти нужную деталь. Но детали там не всегда описаны по одной и той же схеме. Работая с этим файлом не всегда легко предугадать то, какие именно ключевые слова соответствуют тем или иным деталям. Например как понять, какое слово, curved sloped или angled, лучше всего характеризует некую деталь сложной формы?

Хотя искать детали можно и в parts.lst, в этом деле нам могут помочь некоторые специальные интернет-ресурсы:

  • Lugnet это пользовательская группа, в которой есть база данных со сведениями о кодах деталей LEGO, построенная на основе сведений, взятых из LDraw.
  • BrickLink хороший каталог деталей.
  • Rebrickable ещё один ресурс, на котором есть каталог деталей.

Другие средства для рендеринга моделей


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

Вот пример команды рендеринга:

$ povray +I1brick.pov +Q11 +W4196 +H2160 +O1brick-high.png

Ниже показан результат визуализации.


Высококачественная визуализация модели

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


LPub3D

Исследование мира LEGO


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

Кроме того, эксперименты с цифровым вариантом LEGO позволяют создавать виртуальные модели, которые могут быть очень сложными, и могут включать в себя любые детали, даже такие, которых нет у создателя модели. Цифровые детали LEGO можно использовать для создания анимаций, для подготовки иллюстраций сложных моделей, или даже для проектирования собственных деталей. В Сети есть несколько сообществ любителей LEGO, и многие из них, вроде BrickHub.org, публикую прекрасные рендеры, в основе которых лежат LDraw-файлы.

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

А вам нравится LEGO?



Подробнее..

Григорий Бакунов об электронном голосовании

06.07.2020 02:17:13 | Автор: admin

Григорий Бакунов


Директор по распространению технологий Яндекса Григорий bobuk Бакунов в эфире Точки на Эхе Москвы поделился мнением о системе голосования, которая использовалась на выборах в городскую думу в 2019 году и на голосовании по вопросу изменения конституции в 2020. Получился любопытный разбор технических деталей для неспециалистов. На Хабре уже была хорошая публикация на эту тему.


Ниже приведена стенограмма эфира, который провёл Александр plushev Плющев. Его реплики выделены полужирным.


Я не делал этого сам, но я помог другому человеку поучаствовать в этом онлайн, поэтому весь процесс я всё-таки посмотрел, и теперь я его знаю.


То есть он голосовал не тайно? Была нарушена тайна голосования? Я прошу обратить на это внимание центризбирком.


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


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


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


Так, что ты имеешь в виду? Прежде всего?


Что это тот же самый, по большому счёту, блокчейн, который, на самом деле, довольно фиктивный. Что это процесс, в котором большая часть того, что относится к нашей безопасности, сделано, на самом деле, на совершенно фиктивном уровне. И очень жаль, что технических специалистов здесь никто не послушал. Я специально пошёл в интернет посмотреть, а были ли умные люди, которые до этого писали: Ребята, а вот как надо. И таких статей, которые рассказывают, как надо, как можно было сделать, чтобы технические специалисты во всё это поверили, очень много. Но, разумеется, это, по честному если, никому не нужно. Можно прямо разбор провести. Вот давайте с самого начала начнём. Смотрите, нам много раз в разных источниках говорили про то, что это блокчейн. А значит ничего подделать нельзя. Но это, на самом деле, чудовищный обман. В данном случае используется вообще-то хорошая, качественная реализация блокчейна. Этот блокчейн называется Exonum. Это довольно крутая разработка, очень качественная, в которую люди вложили много усилий, чтобы в ней действительно ничего нельзя было подделать. Если бы не одно но. Там такая структура, в которой есть узлы, которые записывают данные в блокчейн, а есть валидаторы. Такая система, которая каждый раз подтверждает, что то, что записано в блокчейн, записано верно. И там невероятно сложная конструкция, которая всё это валидирует. Она продумана так, что для того, чтобы убедить систему записать поддельные данные, или сказать, что какая-то часть данных поддельная, тебе нужно завладеть более, чем двумя третями плюс одним узлом. То есть если у тебя их десять, то тебе нужно, чтобы у тебя в этой системе было семь узлов, чтобы сказать, что запись, которая проведена в блокчейн, она неправильная. Но тут есть один тонкий момент. Я специально пошёл и специально проверил. Все валидаторы, на самом деле, принадлежат государству. Все до одного.


Поясни, что это значит. Чем это чревато?


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


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


Оно может подвергаться изменению в процессе. Как это выглядит. Вот смотрите, в чём идея блокчейна. В том, что в каждой последующей записи есть информация о предыдущих записях. Таким образом, если ты хочешь изменить какую-то запись, например, на пять от текущего момента назад, тебе придётся изменить не только её, но и пять последующих. Так вот в текущей ситуации с текущим блокчейном сделать это довольно легко, это несложная история. Мы об этом говорили ещё и во время московских выборов. С тех пор ничего глобально не поменялось, к сожалению. При этом, смотрите, в основе этого оригинального блокчейна, который называется Exonum, в нём была даже для этого предусмотрена специальная фишка, которая называлась Anchoring. Ну, как сказать, якорение. Идея была такая: раз в какое-то время записывать контрольную сумму, то есть записывать информацию о транзакциях, которые через этот блокчейн прошли, в другой блокчейн, не зависящий от этого. Например, в блокчейн биткойна. В систему, которая показательно независима, и поэтому ты там ничего поделать не можешь. Разумеется, эта фича была выключена, выпилена и никак не использовалась. В Exonum была отдельная такая сущность, которая называлась узлы аудита. Которые не могут ничего писать, но которые могут только проверять информацию. И которые можно было выдать, не знаю, мне, например, или тебе, чтобы ты был руководителем этого узла и мог смотреть, что там происходит. Но они тоже не были предоставлены. Не было классической истории про новый блокчейн, которая называется контроль развёртывания. Это такая практика, при которой, когда разворачивается новый блокчейн на серверах, туда пускаются специальные люди, которые контролируют, что в блокчейне на момент разворачивания нет никакой подделки, нет никаких непонятных действий внутри. Вы понимаете, сейчас единственное, что мы знаем про текущий блокчейн, это текущие транзакции, которые прямо сейчас по нему проходят. Но мы не знаем, не было ли туда доложено предварительно большое количество других транзакций. Мы ничего про это не знаем. Большое количество дополнительной информации Блин, прости, что я монологом говорю.


Давай-давай, интересно.


Я покопал большое количество дополнительной информации. И вот статья, которую ты мне скинул Спасибо тебе большое за неё, потому что я бы, конечно, сам не взялся, а так я просто проверил. Действительно, выяснилось, что довольно простым набором действий можно подтвердить, что голосование было устроено Вот как сейчас, смотрите. Вы заходите на сайт. Для простоты, mos.ru. Вы получаете там, грубо говоря, разрешение или бюллетень на голосование. Там генерируется особенная строчка в вашем собственном браузере, и после этого, внимание, эта строчка отправляется на сервер, который называется elec.moscow. Я пошёл специально посмотреть по адресам, где находятся эти замечательные сервера, которые называются elec.moscow. И там, внезапно, знаете, такие странные штуки: московский минздрав, штука, которая, вот я до сих пор не знаю, что такое Moscow District Council. Ты мне можешь сказать? Я не знаю.


Районный совет?


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


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


В процессе его можно подмешивать, да. И изменять, как тебе хочется, всё так.


И второе, что его можно проконтролировать.


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


У главного редактора, ты имеешь в виду.


У главного редактора, прости пожалуйста, а почему я сказал у генерального директора?


Не знаю.


Наверное, заволновался. Ну, ты понял меня.


Да.


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


Подожди, что за сайт ты имеешь в виду?


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


Ты имеешь в виду constitution.observer?


Да-да. Что-то такое там было. Я, к сожалению, не очень запоминаю...


Нет, боюсь, не то. Я, правда, не знал даже о таком.


Ты можешь посмотреть, у нас с тобой где-то в новостях была ссылка на этот сайт. Нет: observer2020.mos.ru. Я тебе сейчас пришлю ссылку, чтобы ты посмотрел на неё. Так вот, на самом деле, на этом сайте очень интересно смотреть за происходящим. Я не очень понимаю, по какой причине там возникают такие флуктуации, когда иногда ноль, иногда одна, а иногда пятьдесят записей в один блок попадает, но, допустим, что это нормально. Но когда выяснилось, что этот сайт по какой-то причине периодически падает, ломается, при том, что заходит на него пять инвалидов Это я сейчас не про конкретных людей, а в смысле пять людей, которые изредка что-то нажимают. Пять, десять, пятнадцать, несколько сотен человек. Это, в общем-то, всё мелочи для вебсайта, конечно. У меня возникает вопрос о квалификации тех людей, которые этот сайт запустили. И, конечно, когда выяснилось, что в работе этого сайта были прямо конкретные проблемы. Например, было несколько часов, когда данные по этим самым закрытым блокам вообще не показывались, то есть создавались нулевые файлы, и историю их было совершенно не посмотреть. И, насколько я знаю, эта история до сих пор не исправлена. Нам остаётся только верить в то, что в блокчейне в этот момент не происходило никаких изменений, потому что нас же не допускают к самому блокчейну, нам предоставляют только вот такой веб-интерфейс, в котором мы можем посмотреть, что в блоке номер 1452184 ноль транзакций. Или одна транзакция.


Да-да-да, есть такое дело.


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


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


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


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


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


Понятно. Слушай, ещё хотел несколько штук Для меня очень комичная ситуация, что сайт, который нам очень долго рекламировали, 2020og.ru, вот он упал утром первого дня голосования и до сих пор, главное, не вставал. Там, по сути, есть информационный сайт, и есть на его поддомене сайт, на котором проходит голосование. Вот информационный сайт упал и лежит. И не встаёт. То есть формально, если бы это было единственное место, где можно узнать о поправках в конституцию, то вы бы больше нигде не узнали, потому что всё, он лежит. Что они сделали. Они просто сделали переадресацию на голосование. Если вы заходите на 2020og.ru, то вы уходите на голосование. И вам говорят, можете вы проголосовать или нет. Всё. Всё остальное закончилось. Это ЦИКовский проект, это уже не ДИТ, это ЦИК делал, центризбирком России. И вот, видимо, это из того же ряда, о котором говорил Григорий Бакунов, насчёт высочайшей квалификации, с которой всё это сделано. Ну, потому что, что тут можно сказать. Это что, не рассчитали нагрузку и поняли, что даже если его поднимут, то лучше и не надо? Или что, объясни.


Ну, у меня нет никакого объяснения. Я думаю, что причина здесь в том, что сайт просто откровенно не выдерживал нагрузку. У программистов, вообще у технарей, которые делают сайты, есть такая традиция: мы, прежде чем запускать какой-нибудь сервис, его, есть такое хорошее слово, обстреливаем. Мы прогоняем через него большой поток ненастоящего, как будто пользовательского, трафика, проверяя, что сайт выдерживает нагрузку. В данном случае, судя по всему, этим никто не озаботился. Вот мы получили этот результат. А то, что на этом сайте с обзёрвером блоков происходило с ошибками, тебя совершенно не удивляет, да? То есть, когда выяснилось, например, что не формируются отчёты, которые вроде бы нам обещали. Что там будут прямо настоящие наблюдатели за голосованием, которые должны по отчётам смотреть...


Отчёты это то, что ты можешь скачать оттуда?


Да. Когда оно просто не формировалось. То есть, нет, не так, вру. Оно формировалось. Видимость того, что отчёты есть, была. Просто отчёты были нулевой длины.


А, это вот то, о чём писали Открытые Медиа насчёт сбоя, который Слушай, а почему произошёл этот сбой, о которых писали Открытые Медиа? Давай я просто напомню, в чём там было дело. Главное, что ДИТ Москвы признал, что сбой произошёл. Организаторы плебисцита не рассчитали размер файлов и забыли, что при многодневном голосовании следует обозначать не только время, но и дату. С вечера первого дня голосования по поправкам к конституции департамент информационных технологий Москвы больше 12 часов публиковал пустые выписки из блокчейн-системы для наблюдения за ходом электронного голосования, обнаружили Открытые медиа. Как удалось выяснить изданию, неполадка произошла из-за проблем, связанных с размером файла. Но не объясняется, почему, собственно, размер файла таковым оказался, непредсказуемым.


Я не знаю, а какой размер-то был непредсказуемым? Нечётный или что? Что такое непредсказуемый размер? Вы заранее знали, какое количество людей придёт голосовать. Было заранее известно, что больше миллиона человек. Какие там могут быть размеры файла? По утверждениям специалистов и по редким замечаниям человека, который всем этим руководил, я не знаю, можно назвать его специалистом или нет, вся проблема была в том, что...


Ты про начальника управления смарт-проектов правительства Москвы Артёма Костырко?


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


Понятно. Я хочу скзать, что Артёма Костырко мы звали сегодня. Мы подумали, что хватит уже с Ильёй Массухом при всём уважении говорить. До голосования поговорили, а теперь, когда система заработала, мы хотели бы поговорить с Артёмом Костырко. Но он не смог посетить сегодня нашу программу, в том числе и удалённо. Так что, может быть, вы опосредованно услышите его либо в других наших передачах, либо в других средствах массовой информации.


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


Кто-то один из нас издевается над московскими властями.


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

Подробнее..

Лабаем на MIDI клавиатуре в Angular

30.06.2020 14:13:12 | Автор: admin

Web MIDI API интересный зверь. Хоть он и существует уже почти пять лет, его все еще поддерживает только Chromium. Но это не помешает нам создать полноценный синтезатор в Angular. Пора поднять Web Audio API на новый уровень!



Ранее я рассказывал про декларативную работу с Web Audio API в Angular.


Программировать музыку, конечно, весело, но что если мы хотим ее играть? В 80-е годы появился стандарт обмена сообщениями между электронными инструментами MIDI. Он активно используется и по сей день, и Chrome поддерживает его на нативном уровне. Это значит, что, если у вас есть синтезатор или MIDI-клавиатура, вы можете подключить их к компьютеру и считывать то, что вы играете. Можно даже управлять устройствами с компьютера, посылая исходящие сообщения. Давайте разберемся, как это сделать по-хорошему в Angular.


Web MIDI API


В интернете не так много документации на тему этого API, не считая спецификации. Вы запрашиваете доступ к MIDI-устройствам через navigator и получаете Promise со всеми входами и выходами. Эти входы и выходы еще их называют портами являются нативными EventTargetами. Обмен данными осуществляется через MIDIMessageEventы, которые содержат Uint8Array сообщения. В каждом сообщении не более 3 байт. Первый элемент массива называется status byte. Каждое число означает конкретную роль сообщения, например нажатие клавиши или движение ползунка параметра. В случае нажатой клавиши второй байт отвечает за то, какая клавиша нажата, а третий как громко нота была сыграна. Полное описание сообщений можно подсмотреть на официальном сайте MIDI. В Angular мы работаем с событиями через Observable, так что первым шагом станет приведение Web MIDI API к RxJs.


Dependency Injection


Чтобы подписаться на события, мы сначала должны получить MIDIAccess-объект, чтобы добраться до портов. navigator вернет нам Promise, а RxJs превратит его для нас в Observable. Мы можем создать для этого InjectionToken, используя NAVIGATOR из @ng-web-apis/common. Так мы не обращается к глобальному объекту напрямую:


export const MIDI_ACCESS = new InjectionToken<Promise<MIDIAccess>>(   'Promise for MIDIAccess object',   {       factory: () => {           const navigatorRef = inject(NAVIGATOR);           return navigatorRef.requestMIDIAccess               ? navigatorRef.requestMIDIAccess()               : Promise.reject(new Error('Web MIDI API is not supported'));       },   },);

Теперь мы можем подписаться на все MIDI-события. Можно создать Observable одним из двух способов:


  1. Создать сервис, который наследуется от Observable, как мы делали в Geolocation API
  2. Создать токен с фабрикой, который будет транслировать этот Promise в Observable событий

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


export const MIDI_MESSAGES = new InjectionToken<Observable<MIDIMessageEvent>>(   'All incoming MIDI messages stream',   {       factory: () =>           from(inject(MIDI_ACCESS).catch((e: Error) => e)).pipe(               switchMap(access =>                   access instanceof Error                       ? throwError(access)                       : merge(                             ...Array.from(access.inputs).map(([_, input]) =>                                 fromEvent(                                     input as FromEventTarget<MIDIMessageEvent>,                                     'midimessage',                                 ),                             ),                         ),               ),               share(),           ),   },);

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


export function outputById(id: string): Provider[] {   return [       {           provide: MIDI_OUTPUT_QUERY,           useValue: id,       },       {           provide: MIDI_OUTPUT,           deps: [MIDI_ACCESS, MIDI_OUTPUT_QUERY],           useFactory: outputByIdFactory,       },   ];}export function outputByIdFactory(   midiAccess: Promise<MIDIAccess>,   id: string,): Promise<MIDIOutput | undefined> {   return midiAccess.then(access => access.outputs.get(id));}

Кстати, вы знали, что нет необходимости спрэдить массив Provider[], когда добавляете его в метаданные? Поле providers декоратора @Directive поддерживает многомерные массивы, так что можно писать просто:

providers: [  outputById(someId),  ANOTHER_TOKEN,  SomeService,]

Если вам интересны подобные практичные мелочи про Angular приглашаю почитать нашу серию твитов с полезными советами.

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


Операторы


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


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

Вот так мы можем слушать события с определенного канала:


export function filterByChannel(   channel: MidiChannel,): MonoTypeOperatorFunction<MIDIMessageEvent> {   return source => source.pipe(filter(({data}) => data[0] % 16 === channel));}

Status byte организован группами по 16: 128143 отвечают за нажатые клавиши (noteOn) на каждом из 16 каналов. 144159 за отпускание зажатых клавиш (noteOff). Таким образом, если мы возьмем остаток от деления этого байта на 16 получим номер канала.


Если нас интересуют только сыгранные ноты, поможет такой оператор:


export function notes(): MonoTypeOperatorFunction<MIDIMessageEvent> {   return source =>       source.pipe(           filter(({data}) => between(data[0], 128, 159)),           map(event => {               if (between(event.data[0], 128, 143)) {                   event.data[0] += 16;                   event.data[2] = 0;               }               return event;           }),       );}

Некоторые MIDI-устройства отправляют явные noteOff-сообщения, когда вы отпускаете клавишу. Но некоторые вместо этого отправляют noteOn сообщение с нулевой громкостью. Этот оператор нормализует такое поведение, приводя все сообщения к noteOn. Мы просто смещаем status byte на 16, чтобы noteOff-сообщения перешли на территорию noteOn, и задаем нулевую громкость.

Теперь можно строить цепочки операторов, чтобы получить стрим, который нам нужен:


readonly notes$ = this.messages$.pipe(  catchError(() => EMPTY),  notes(),  toData(),);constructor(  @Inject(MIDI_MESSAGES)  private readonly messages$: Observable<MIDIMessageEvent>,) {}

Пора применить все это на практике!


Создаем синтезатор


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


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


readonly notes$ = this.messages$.pipe(  catchError(() => EMPTY),  notes(),  toData(),  scan(    (map, [_, note, volume]) => map.set(note, volume), new Map()  ),);

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



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


@Pipe({    name: 'adsr',})export class AdsrPipe implements PipeTransform {    transform(        value: number,        attack: number,        decay: number,        sustain: number,        release: number,    ): AudioParamInput {        return value            ? [                  {                      value: 0,                      duration: 0,                      mode: 'instant',                  },                  {                      value,                      duration: attack,                      mode: 'linear',                  },                  {                      value: sustain,                      duration: decay,                      mode: 'linear',                  },              ]            : {                  value: 0,                  duration: release,                  mode: 'linear',              };    }}

Теперь, когда мы нажимаем клавишу, громкость будет линейно нарастать за время attack. Затем она убавится до уровня sustain за время decay. А когда мы отпустим клавишу, громкость упадет до нуля за время release.

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


<ng-container  *ngFor="let note of notes | keyvalue; trackBy: noteKey">  <ng-container    waOscillatorNode    detune="5"    autoplay    [frequency]="toFrequency(note.key)"   >    <ng-container       waGainNode       gain="0"      [gain]="note.value | adsr: 0:0.1:0.02:1"    >      <ng-container waAudioDestinationNode></ng-container>    </ng-container>  </ng-container>   <ng-container    waOscillatorNode    type="sawtooth"    autoplay     [frequency]="toFrequency(note.key)"  >    <ng-container       waGainNode      gain="0"      [gain]="note.value | adsr: 0:0.1:0.02:1"    >      <ng-container waAudioDestinationNode></ng-container>      <ng-container [waOutput]="convolver"></ng-container>    </ng-container>  </ng-container></ng-container><ng-container  #convolver="AudioNode"  waConvolverNode  buffer="assets/audio/response.wav">  <ng-container waAudioDestinationNode></ng-container></ng-container>

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


https://ng-web-apis.github.io/midi


Если у вас нет MIDI клавиатуры можете понажимать на ноты мышкой.


Живое демо доступно тут, однако браузер не позволит получить доступ к MIDI в iframe: https://stackblitz.com/edit/angular-midi

Заключение


В Angular мы привыкли работать с событиями с помощью RxJs. И Web MIDI API не сильно отличается от привычных DOM событий. С помощью пары токенов и архитектурных решений мы смогли с легкостью добавить поддержку MIDI в наше Angular приложение. Описанное решение доступно в виде open-source библиотеки @ng-web-apis/midi. Она является частью большого проекта, под названием Web APIs for Angular. Наша цель создание легковесных качественных оберток для использования нативного API в Angular приложениях. Так что если вам нужен, к примеру, Payment Request API или Intersection Observer посмотрите все наши релизы.


Если вам любопытно, что же такого интересного можно сделать на Angular при помощи Web MIDI API приглашаю вас научиться играть на клавишах в личном проекте Jamigo.app

Подробнее..

Альтернативная конституция

01.07.2020 22:06:22 | Автор: admin
Мы вовсе не собираемся разрушать ваш старый мир. Мы собираемся построить новый. Вот вы жестоки: вы не представляете себе строительство нового без разрушения старого. А мы представляем себе это очень хорошо. Мы даже поможем вашему поколению создать этот ваш рай, выпивайте и закусывайте на здоровье. Строить, господин Банев, только строить. Ничего не разрушать, только строить.
А и Б Стругацкие, Гадкие лебеди

image


Этот пост я задумываю как рискованный эксперимент. Я хочу выяснить, могут ли ИТишники самоорганизоваться для создания открытого, свободного (от слова freedom, а не free beer), чистого, высококлассного кода, используя привычные им инструменты (Git, fork, TDD, agile, stackoverflow и прочее). Только этот код это текст, который мог бы являться конституцией в альтернативной реальности (или фантастического рассказа), очень близкой к нашей. Если тебе не нравится чужой код напиши свой.

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

Заодно попробуем составить базу знаний лучших решений, какие были за историю конституций всех времен и народов, методов написаний и улучшений, а так же dark pattern'ы. Например, довольно поучительный кейс Исландии, как они писали-писали вики-конституцию, но так и не написали. Не помогли ни кастрюли, ни батя Бьорк, ни то, что их всего 300 000 человек.

(Надеюсь, что читатели Хабра смогут отнестись к моей идее конструктивно и не превратят в балаган. Если превратят то скрою статью и завершу эксперимент.)


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


Истории конституций


Теория общественного договора определяет Конституцию как договор между населением и государством, где определяется порядок формирования государства и взаимоотношение сторон.

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

image

Копия Великой хартии вольностей

image

Первая страница оригинального текста Конституции Соединённых Штатов

Первой конституцией в современном смысле этого понятия, то есть документ, описывающий и устанавливающий разделение властей и компетенцию каждой из них, является Конституция США, ратифицированная штатом Делавэр 7 декабря 1787 года

image

К первым писаным конституциям на Европейском континенте также относят Конституцию Речи Посполитой (принята 3 мая 1791 года) и Конституцию Франции (принята 3 сентября 1791 года). Обе конституции просуществовали недолго, в Речи Посполитой из-за окончательного раздела страны, во Франции из-за развития революционных событий.

image

Конституция казаков Филиппа Орлика 1710 года

Конституции составляются и принимаются:

  • чрезвычайно-созываемым парламентом (учредительное собрание) (например, Конституция Франции, Конституция Италии 1947 года, Конституция Чехословакии 1948 года, Конституция Югославии 1946 года, Конституция Румынии, Конституция Албании 1946 года, Конституция Германии 1918 года, Конституция Греции, Конституции Болгарии, Конституции Польши 1920 и 1952 годов, Конституция Норвегии);
  • регулярным парламентом (например, Конституция Дании, Конституция РСФСР 1978 года, Конституция ГДР 1968 года, конституции Венгрии 1949 и 2011 года, Конституция Польши 1997 года)
  • съездом советов депутатов (Конституция РСФСР 1918 года, 1925 года, 1937 года)
  • временным парламентом (Конституция Чехословакии 1919 года, Конституция ФРГ 1949 года, Конституция ГДР 1949 года)
  • народом, минуя выборные органы (Конституция Франции 1958 года, Конституция России 1993 года)
  • главой государства (Конституция Германии 1871 года, Конституция Франции 1814 года, Конституция Италии 1861 года, Основные Законы Российской Империи 1906 года);


Конституция Исландии


Из Википедии:

Главной задачей на повестке нового правительства стала разработка новой конституции. Первую попытку написания конституции правительство предприняло сразу после прихода к власти. Предполагалось, что на это уйдет год, но в итоге дело закончилось неудачей, потому что граждане не хотели признавать такую конституцию легитимной. Тогда правительство решилось на эксперимент: сделать так, чтобы граждане сами написали конституцию. Существует миф, что проект основного закона писали 950 простых граждан, но это не так. На первом этапе реформы действительно был собран Национальный форум, состоящий из 950 человек. Форум формировался жеребьевкой. Он определил ключевые ценности и направления новой конституции. Далее 7 профессиональных политиков составило заключение состоящие из 700 страниц. Чтобы доработать новую Конституцию, было избрано Конституционное собрание, в который вошли 25 граждан. В распространенном в интернете мифе говорится, что это собрание состояло из домохозяек, крестьян, рабочих и т. д., но в действительности совет состоял из семи руководителей (университетов, музеев, профсоюзов), кроме того, пяти профессоров и доцентов, четырёх представителей средств массовой информации, четырёх художников, двух юристов, священника, отца певицы Бьорк, видного профсоюзного деятеля и всего одного крестьянина. Совет должен был быть избран. Для этого кандидаты собирали по 30 подписей. Свою кандидатуру предложили 522 человека. 25 человек были избраны на всенародных выборах. Но в итоге голосование было признано парламентом недействительным, а членов собрания они назначали сами. Далее началась доработка текста Конституции и конституционных законов. От каждого гражданина требовалось посылать предложения по электронной почте, Facebook или YouTube и участвовать в обсуждениях Совета, давая комментарии и рекомендации.

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


Интересные ИТ-ресурсы


Подробнее..

Много eBook-ов, контейнеры Jenkins, Tekton Pipelines и 6 уроков по Istio Service Mesh

26.06.2020 16:08:22 | Автор: admin


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

Строй:



Начни новое:


  • Интерактивный tutorial: Istio Service Mesh Workshop (10 уроков | 6 часов 10 минут)
    Установите Istio на кластер Kubernetes и разверните три микросервиса. Поэкспериментируйте с мониторингом, трассировкой, маршрутизацией и fault injection, прежде чем выполнять более сложные задачи с помощью Egress, Kiali и mTLS.
  • Cheat sheet: Как написать Kubernetes Operator в/на Java



    Эта шпаргалка про то, как создать Kubernetes Operator в Java с помощью Quarkus. Код CRD и Java, регистрация CRD в клиенте Kubernetes, внедрение и развертывание Operator.
  • eBook: Streamline microservice management with Istio
    Istio это реализация service mesh, которая повышает устойчивость приложений при подключении, управлении и защите микросервисов. Это уже второе издание, повествующее о ключевых возможностях микросервисов, которые Istio предоставляет для Kubernetes и OpenShift.
  • Tutorial: Использование Ansible Collections для настройки и управления сложными (complex) системами
  • Запись вебинара про Red Hat CodeReady
    Рассказываем про инструмент для разработчиков, который делает разработку облачных приложений применимой для командной работы: используя Kubernetes и контейнеры, вы предоставляете любому члену команды разработчиков или ИТ-специалистам согласованную, предварительно сконфигурированную среду разработки и тестирования. Разработчики могут создавать код, собирать приложения и тестировать в контейнерах, работающих на Red Hat OpenShift. Пользовательский интерфейс такой же быстрый и привычный, как и интегрированная среда разработки (IDE) на любимом ноутбуке.

Пообщаться:


  • 6 июля 2020 г.
    Master Course: Kubernetes для начинающих
    Применяйте, разворачивайте и используйте Kubernetes для удовлетворения ваших собственных облачных требований.
  • 8 июля 2020 г.
    Master Course: Kubernetes для продолжающих
    Выполняйте плавные обновления с правильными датчиками работоспособности и готовности и управляйте настройкой своих приложений.

По-русски:


  • Вебинар: Red Hat OpenStack Platform
    Накануне выхода Red Hat OpenStack Platform 16.1 мы расскажем о последних дополнениях и улучшениях продукта, являющегося эффективной инновационной IaaS-платформой, оптимально подходящей для задач построения гибридного облака и сотен Kubernetes кластеров, виртуализации сетевых функций (NFV), периферийных вычислений (edge), машинного обучения и искусственного интеллекта.
  • Вебинар: CI/CD и Kubernetes
    16 июля только у нас и только для вас Дмитрий Севостьянов, заслуженный архитектор Red Hat, расскажет про собственный взгляд на разработку и CI/CD:
    1) сборка простого приложения (микросервиса);
    2) интеграция микросервисов с другими приложениями или сервисами за пределами кластера OpenShift;
    3) возможности по интеграции с серверами Single-Sign-On;
    4) переход от простой сборки к конвейерам (CI/CD):
    4а) классический конвейер Jenkins
    4b) конвейер, ориентированный на kubernetes-подобные среды tekton
    4c) чудо-операторы самое современное решение при доставке и управлении приложениями.
Подробнее..

Интеграция Open vSwitch с Р-виртуализацией

01.07.2020 10:24:00 | Автор: admin

Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.


Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.



Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.


Железо


Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.


Развертывание РП


Краткая инструкция по установке:


  • 1. Устанавливаем первую ноду, в анаконде назначаем IP хосту и из этой же подсети виртуальный IP для управления Р-виртуализации, и IP для управления Р-хранилищем. Дисков как минимум должно быть 3, один для хоста (ОС/гипервизор) в моем случае HDD, второй и третий диск уже настроим через управление Р-хранилищем, где один SSD под кэш и другой под чанк сервер. На втором интерфейсе назначаем IP из другой подсети для сети хранения без шлюза.
  • 2. После установки заходим через браузер хром по IP адресу управления Р-хранилищем, далее выбираем раздел серверы и нажимаем на вопросик с прямоугольником, и выбираем раздел сеть, в нем назначаем роли для интерфейса с адресом подсети управления(роли ssh, управление, web cp) и для интерфейса с подсетью для хранения назначаем роли (ssh, хранилище).
  • 3. Далее нажимаем создать кластер вводим его имя автоматом должен подключится интерфейс с ролью хранения и выбрать подробные настройки, убедится что система правильно распределила роли на дисках, один должен быть системный, другой служба метаданных плюс кэш если это SSD и далее третий диск HDD в роли хранения (чанк сервер).
  • 4. Параллельно с установкой первой ноды можно устанавливать две последующие, назначить каждой по два IP адреса один для подсети управления Р-виртуализации, на втором интерфейсе из подсети хранения. Если оставить поля регистрации на сервере управления Р-виртуализации и управления Р-хранилище пустыми то, можно продолжить установку без указания IP адресов управления, а регистрацию выполнить потом.
  • 5. После того как последующие ноды установлены пройти по IP адресу этих хостов через ssh в cli и выполнить регистрацию, где IP это адрес управления Р-хранилищем и токен можно скопировать с веб управления р-хранилищем при нажатии добавить ноду.
  • 6. После того как обе ноды появятся в веб управлениии Р-хранилище выполнить те же действия что в пункте 2-3 только вместо создания кластера выбрать присоединить.
  • 7. Далее после создания кластера появится пункт сервисы в нем создать хранилище датастор в зависимости наличия дисков и узлов можно делать реплику 2 или 3 и т.д. если узла 3 то, реплика 2, остальное все по умолчанию.
  • 8. Далее проходим по IP адресу управления Р-виртуализации нажимаем добавить если физ. сервер если не добавлен и добавляем остальные, далее устанавливаем триал лицензию, далее в настройках хоста выполнить Изменение настроек хоста для виртуальных сред выбрать вместо локальной папки по умолчанию можно для всех пунктов(для первого раза лучше так) выбираем наш датастор который создавали в Р-хранилище и ставим галочку применить на все хосты.
  • 9. После это мигрируем vstorage-ui и va-nm на любой другой хост, время может занять некоторое потому что это миграция с локальных носителей на кластерные.
  • 10. После этого открываем ssh консоли всех трех узлов и вводим команду включения HA на каждом узле, где IP адрес сети хранения, после этого необходимо проверить командой #shaman stat
  • 11. После этого можно приступать к созданию ВМ, где я в качестве гостевой установил CentOS 7.

команда регистрации ноды к выше описанному пункту 5:


#/usr/libexec/vstorage-ui-agent/bin/register-storage-node.sh -m 10.43.10.14 -t ec234873

комнда включения HA к пункту 10:


#hastart -c имя кластера -n 192.168.10.0/24 

и проверка HA, где вывод должен быть примерно такой:


[root@n3 ~]# shaman statCluster 'rptest'Nodes: 3Resources: 7    NODE_IP           STATUS     ROLES                RESOURCES    192.168.10.10     Active     VM:QEMU,CT:VZ7       0 CT, 0 VM    192.168.10.11     Active   VM:QEMU,CT:VZ7       0 CT, 0 VM*M 192.168.10.12     Active     VM:QEMU,CT:VZ7       2 CT, 0 VM

Установка и настройка OVS


На первой и третей ноде кластера были установлены OVS следующей командой:


#yum install openvswitch 

После установки можно проверить командой


#ovs-vsctl show 

Вывод будет примерно следующий:


[root@node1 ~]# ovs-vsctl show180c5636-2d3d-4e08-9c95-fe5e47f1e5faovs_version: "2.0.0"[root@node1 ~]#

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


# ovs-vsctl add-br ovsbr0 

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


#ovs-vsctl add-br brlv140 ovsbr0 140 

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


<network> <name>ovsvl</name> <forward mode='bridge'/> <bridge name='brlv140'/> <vlan>  <tag id='140'/></vlan><virtualport type='openvswitch'/></network>

К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:


#virsh net-list --all 

Для добавления нашей сети:


#virsh net-define ovsvl.xml 

Далее необходимо ее запустить/активировать


#virsh net-start ovsvl

И прописать в автостарт


#virsh net-autostart ovsvl

Далее необходимо добавить эту сеть к ВМ


#virsh edit имяВМ 

Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):


<interface type='bridge'>      <mac address='00:1c:42:c6:80:06'/>

  <vlan>    <tag id='140'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='5a70be5b-5576-4734-9f61-61cdfc4a884a'/>  </virtualport>  <target dev='vme001c42c68006'/>  <model type='virtio'/>  <boot order='2'/>  <alias name='net0'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></interface>


Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:


#prlctl stop имя ВМ

#prlctl start имя ВМ

Для проверки можно ввести команду:


#virsh dumpxml имяВМ | grep имясети 

После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.12 

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


#ip link set mtu 2000 dev ens3f0

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


На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.10

Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:


#tcpdump i ens3f0 | grep 4789``` то можно увидеть пакеты с vxlan или c тегами vlan ```bash#tcpdump -ee -vvv -i ens3f0 | grep vlan

Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:


 <network><name>ovsvl2</name><forward mode='bridge'/><bridge name='ovsbr0'/><virtualport type='openvswitch'/><portgroup name='vlan-120'>    <vlan>      <tag id='120'/>    </vlan>  </portgroup></network>

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


<interface type='bridge'>      <mac address='00:1c:42:c8:f1:cd'/>

  <vlan>    <tag id='120'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='ef717aa4-23b3-4fbe-82bb-193033f933b1'/>  </virtualport>  <target dev='vme001c42c8f1cd'/>  <model type='virtio'/>  <boot order='3'/>  <alias name='net1'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/></interface>


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


#ovs-vsctl set port ens3f4 trunks=120,130#ovs-vsctl add-port ovsbr0 ens3f4  

И можно добавить порт с тегом 120 для ВМ:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

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


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

Плюс добавить сеть как описано выше.


Пример вывода настроек OVS и ВМ



Вывод команды #ovs-vsctl show на первой ноде. Порты и интерфейсы с именем начинающимся с vme являются виртуальными интерфейсами ВМ, которые автоматически попадают в конфиг при запуске ВМ подключенному к OVS.



Вывод команды #ovs-vsctl show на третей ноде



Вывод команды virsh net-list содержит 4 вида сети, где Bridged и Host-Only это стандартные классические варианты от Р-виртуализации по дефолту, а ovsvl и ovsvl2 это то, что мы добавили по инструкции выше. Ovsvl получается для варианта с тегированным мостом tag 140 поверх моста OVS, а ovsvl2 это вариант с группой портов portgroup состоящей из одного порта с tag 120. Portgroup очень удобен и в него можно добавлять больше одного порта используя только одну сеть вместо большого количества сетей в классическом варианте Р-виртуализации с мостами под которыми разные VLAN интерфейсы. Далее вывод команды #virsh net-dumpxml ovsvl и ovsvl2 показывающие содержимое настроек этих сетей.



Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:


 #virsh dumpxml имяВМ

Тесты


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


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


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



На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.


Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.


По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.


Описание сценариев


Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.



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



Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.


Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке



В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.


Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища. Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.


Как работает классический br0 я описывать не буду, ovsbr0 работает со IP стеком ОС, который на этой картинке определен для br0, то есть экземпляр виртуального коммутатора в виде ovsbr0 работает в данном случае через br0. Другими словами статический IP адрес ноды назначен на классический br0 и весь трафик, который направлен в эту подсеть с виртуального коммутатора проходит через br0, так же как это работает для всех приложений этой ноды. С точки зрения настройки в этом случае никаких cli назначений на br0 со стороны виртуального коммутатора не производилось кроме настройки vxlan интерфейса с option, соответственно если у ноды есть второй классический br1 c другим IP адресом и подсетью висящий на другом физическом порту например eth2 или eth3 то, с виртуального коммутатора за счет стека ОС и его таблицы mac-ов можно направить пакеты в эти подсети назначив какой либо порт виртуального коммутатора в эту подсеть и подключить к ВМ, адрес подсети будет непосредственно назначаться внутри ВМ или в ее настройках.


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



У виртуального коммутатора есть своя таблица маков.


У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.


Теоретически мы можем представить, что когда в какой-то порт коммутатора прилетает фрейм с VLAN тегом, то решение о дальнейшей отправке фрейма принимается на основании таблицы mac адресов соответствующего виртуального коммутатора. Если получен фрейм с тегом 120, то соответственно приниматься решение о форвардинге данного фрейма будет на основании mac таблицы виртуального коммутатора с тегом 120.


Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее VxLAN тоннель коммутатор воспринимает как простой транковый порт.


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


Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.


Заключение


При выполнении настроек OVS понравилась простота, удобносто, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.


Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
1)https://www.sidorenko.io/post/2018/11/openstack-networking-open-vswitch-and-vxlan-introduction/
2) https://blog.remibergsma.com/2015/03/26/connecting-two-open-vswitches-to-create-a-l2-connection/
3)http://mx54.ru/nastrojka-setevyx-interfejsov-v-kvm-dlya-virtualnyx-mashin/
4) https://kamaok.org.ua/?p=2677
5)https://kashyapc.fedorapeople.org/virt/add-network-card-in-guest.txt
6)https://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/#.XuZ960UzaM_

Подробнее..

Recovery mode От стартапа до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры

03.07.2020 20:16:17 | Автор: admin
Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.



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

В целом, можно сказать, что наша команда поставляет для компании 2 продукта. Первый это инфраструктура. Почта должна ходить, DNS работать, а контроллеры домена пускать вас на сервера, которые не должны падать. IT ландшафт компании огромен! Это business&mission critical системы, требования по доступности некоторых 99,999. Второй продукт сами сервера, физические и виртуальные. За существующими нужно следить, а новые регулярно поставлять заказчикам из множества подразделений. В этой статье я хочу сделать акцент на том, как мы развивали инфраструктуру, которая отвечает за жизненный цикл серверов.

Начало пути

В начале пути наш стек технологий выглядел так:
ОС CentOS 7
Контроллеры домена FreeIPA
Автоматизация Ansible(+Tower), Cobbler


Всё это располагалось в 3х доменах, размазанных на нескольких ЦОДах. В одном ЦОД офисные системы и тестовые полигоны, в остальных ПРОД.

Создание серверов в какой-то момент выглядело так:



В шаблоне VM CentOS minimal и необходимый минимум вроде корректного /etc/resolv.conf, остальное приезжает через Ansible.

CMDB Excel.

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

Поначалу мы даже пытались делать какой-то configuration management в Cobbler. Но со временем это стало приносить проблемы с переносимостью конфигураций как в другие ЦОД, так и в Ansible код для подготовки VM.

Ansible в то время многие из нас воспринимали как удобное расширение Bash и не скупились на конструкции с использованием shell, sed. В общем Bashsible. Это в итоге приводило к тому, что, если плейбук по какой-либо причине не отрабатывал на сервере, проще было удалить сервер, поправить плейбук и прокатить заново. Никакого версионирования скриптов по сути не было, переносимости конфигураций тоже.

Например, мы захотели изменить какой-то конфиг на всех серверах:

  1. Изменяем конфигурацию на существующих серверах в логическом сегменте/ЦОД. Иногда не за один день требования к доступности и закон больших чисел не позволяет применять все изменения разом. А некоторые изменения потенциально деструктивны и требуют перезапуск чего-либо от служб до самой ОС.
  2. Исправляем в Ansible
  3. Исправляем в Cobbler
  4. Повторяем N раз для каждого логического сегмента/ЦОД

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

  • Рефакторинг ansible кода, конфигурационных файлов
  • Изменение внутренних best practice
  • Изменения по итогам разбора инцидентов/аварий
  • Изменение стандартов безопасности, как внутренних, так и внешних. Например, PCI DSS каждый год дополняется новыми требованиями

Рост инфраструктуры и начало пути

Количество серверов/логических доменов/ЦОД росло, а с ними количество ошибок в конфигурациях. В какой-то момент мы пришли к трём направлениям, в сторону которых нужно развивать configuration management:

  1. Автоматизация. Насколько возможно, нужно избегать человеческого фактора в повторяющихся операциях.
  2. Повторяемость. Управлять инфраструктурой намного проще, когда она предсказуема. Конфигурация серверов и инструментов для их подготовки должна быть везде одинаковой. Это так же важно для продуктовых команд приложение должно гарантированно после тестирования попадать в продуктивную среду, настроенную аналогично тестовой.
  3. Простота и прозрачность внесения изменений в configuration management.

Осталось добавить пару инструментов.

В качестве хранилища кода мы выбрали GitLab CE, не в последнюю очередь за наличие встроенных модулей CI/CD.

Хранилище секретов Hashicorp Vault, в т.ч. за прекрасное API.

Тестирование конфигураций и ansible ролей Molecule+Testinfra. Тесты идут намного быстрее, если подключаете к ansible mitogen. Параллельно мы начали писать собственную CMDB и оркестратор для автоматического деплоя (на картинке над Cobbler), но это уже совсем другая история, о которой в будущем расскажет мой коллега и главный разработчик этих систем.

Наш выбор:

Molecule + Testinfra
Ansible + Tower + AWX
Мир Серверов + DITNET(Собственная разработка)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault




Кстати про ansible роли. Сначала она была одна, после нескольких рефакторингов их стало 17. Категорически рекомендую разбивать монолит на идемпотентные роли, которые можно потом запускать отдельно, дополнительно можно добавить теги. Мы роли разбили по функционалу network, logging, packages, hardware, molecule etc. А вообще, придерживались стратегии ниже. Не настаиваю на том, что это истина в единственной инстанции, но у нас сработало.

  • Копирование серверов из золотого образа зло!

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

    1. Оставьте /etc/sysctl.conf пустым, настройки должны лежать только в /etc/sysctl.d/. Ваш дефолт в один файл, кастом для приложения в другой.
    2. Используйте override файлы для редактирования systemd юнитов.
  • Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
  • Рефактория код системы управления конфигурациями:

    1. Разбейте задачи на логические сущности и перепишите монолит на роли
    2. Используйте линтеры! Ansible-lint, yaml-lint, etc
    3. Меняйте подход! Никакого bashsible. Нужно описывать состояние системы
  • Под все Ansible роли нужно написать тесты в molecule и раз в день генерировать отчёты.
  • В нашем случае, после подготовки тестов (которых больше 100) нашлось около 70000 ошибок. Исправляли несколько месяцев.


Наша реализация

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



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

Вариантов создания серверов тоже много. Мы в итоге выбрали кастомные скрипты на питоне. А для CI ansible:

- name: create1.yml - Create a VM from a template  vmware_guest:    hostname: "{{datacenter}}".domain.ru    username: "{{ username_vc }}"    password: "{{ password_vc }}"    validate_certs: no    cluster: "{{cluster}}"    datacenter: "{{datacenter}}"    name: "{{ name }}"    state: poweredon    folder: "/{{folder}}"    template: "{{template}}"    customization:      hostname: "{{ name }}"      domain: domain.ru      dns_servers:        - "{{ ipa1_dns }}"        - "{{ ipa2_dns }}"    networks:      - name: "{{ network }}"        type: static        ip: "{{ip}}"        netmask: "{{netmask}}"        gateway: "{{gateway}}"        wake_on_lan: True        start_connected: True        allow_guest_control: True    wait_for_ip_address: yes    disk:      - size_gb: 1        type: thin        datastore: "{{datastore}}"      - size_gb: 20        type: thin        datastore: "{{datastore}}"

Вот к чему мы пришли, система продолжает жить и развиваться.

  • 17 ansible-ролей для настройки сервера. Каждая из ролей предназначена для решения отдельной логической задачи (логирование, аудит, авторизация пользователей, мониторинг и т.д.).
  • Тестирование ролей. Molecule + TestInfra.
  • Собственная разработка: CMDB + Оркестратор.
  • Время создания сервера ~30 минут, автоматизировано и практически не зависит от очереди задач.
  • Одинаковое состояние/именование инфраструктуры во всех сегментах плейбуки, репозитории, элементы виртуализации.
  • Ежедневная проверка состояния серверов с генерацией отчётов о расхождениях с эталоном.

Надеюсь мой рассказ будет полезен тем, кто в начале пути. А какой стек автоматизации используете вы?
Подробнее..

Наши уникальные бесплатные мастер-курсы Kubernetes, CLI tool для разработчиков Odo, Java в контейнерах и много книг

04.07.2020 00:19:48 | Автор: admin
Окей, мы инновационная ИТ-компания, а значит у нас есть разработчики и это хорошие разработчики, увлеченные своим делом.



А еще они проводят live streaming, и все вместе это называется DevNation.

Начни новое:



Строй:



Немного от HR:


  • Как просить повышения во время COVID-19
    Несмотря на то, что пандемия заставляет многие компании сокращать свои бюджеты, технические навыки необходимы как никогда. Используйте эти советы, чтобы доказать свою ценность и получить повышение заработной платы в неспокойное время.
  • 3 совета, чтобы избежать выгорания во время работы из дома
    Статья в Harvard Business Review с тремя надежными пунктами по борьбе с выгоранием, а еще советы для работодателей, менеджеров и коллег, которые хотят помочь.

Пообщаться:


Ежемесячные вебинары для разработчиков от бабушкиМаркуса, главы Developer Adoption Program. Маркус приглашает друзей для обмена опытом в проектировании и создании современных приложений.



Список ближайших тем:

  • Quarkus the black swan of Java
  • Helm for Developers
  • Supersonic Secure Java with Quarkus
  • Stream Processing with Quarkus, Kafka Streams and Knative
  • Securing Microservices
  • DevOps with Containers
  • Orchestrating microservices the cloud-native way

По-русски:


Подробнее..

Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать. Алексей Зателепин (2018г)

04.07.2020 16:09:21 | Автор: admin

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


Будут затронуты следующие темы:


  • Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
  • Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
  • Как диагностировать проблемы на production-кластере ClickHouse.


Видео:



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



Я ClickHouse занимаюсь недавно. До этого я несколько лет работал в Яндекс.Картах. Был прикладным разработчиком. Много там работал с базами данных, с Postgres, поэтому я еще вирусом ClickHouse не сильно заражен, я еще помню, что такое быть прикладным разработчиком. Но, в принципе, уже все довольно хорошо понимаю.



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


У нас есть некие события. Они постоянно приходят. Я тут выписал какие-то примеры. Вот Яндекс.Метрика это сервис, для которого ClickHouse изначально создавался.


  • Это какие-то действия пользователя на сайте.
  • Реклама.
  • Финансовые транзакции, покупки в магазинах.
  • И DNS-запросы.

Что мы хотим с этими событиями сделать? Мы хотим о них сохранить информацию и что-то о них понять потом, т. е. построить какие-то отчеты, аналитику, потом на них посмотреть и что-то понять.



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


Для ClickHouse самое важное:


  • Это интерактивные запросы. Что это такое? Это выполнение за секунды, а лучше меньше, чем за секунду. Почему это важно? Во-первых, когда Яндекс.Метрика показывает отчет, пользователь не будет ждать, если он загружается больше секунды. Но даже если вы, как аналитик, работаете с ClickHouse, с базой данной, то очень хорошо, если ответы на запросы тут же приходят. Вы тогда их можете много задать. Вы можете не отвлекаться. Вы можете погрузиться в работу с данными. Это другое качество работы.
  • Язык запросов у нас SQL. Это тоже и плюсы, и минусы. Плюсы в том, что SQL декларативный и поэтому простой запрос можно очень хорошо оптимизировать, т. е. очень оптимально выполнить. Но SQL не очень гибкий. Т. е. произвольную трансформацию данных с помощью SQL не задать, поэтому там у нас куча каких-то расширений, очень много функций дополнительных. А преимущество в том, что SQL все аналитики знают, это очень популярный язык.
  • Стараемся ничего заранее не агрегировать. Т. е. когда такую систему делаешь, то очень велик соблазн сначала подумать о том, какие отчеты нужны. Подумать, что у меня события будут поступать, я их буду потихоньку агрегировать и нужно будет показать отчет, я быстренько вот это все покажу. Но есть проблема такого подхода. Если вы два события слили вместе, то вы уже их ни в каком отчете больше не различите. Они у вас вместе. Поэтому чтобы сохранить гибкость, стараемся всегда хранить индивидуальные события и заранее ничего не агрегировать.
  • Еще один важный пункт, который требуется от прикладного разработчика, который работает с ClickHouse. Нужно заранее понять, какие есть атрибуты события. Нужно их самому выделить, вычленить и уже эти атрибуты запихивать в ClickHouse, т. е. какие-то json в свободной форме или текстовые blob, которые вы просто берете и пихаете, и надеетесь потом распарсить. Так лучше не делать, иначе у вас интерактивных запросов не будет.


Возьмем пример достаточно простой. Представим, что мы делаем клон Яндекс.Метрики, систему веб-аналитики. У нас есть счетчик, который мы на сайт ставим. Он идентифицируется колонкой CounterID. У нас есть таблица hits, в которую мы складываем просмотры страниц. И есть еще колонка Referer, и еще что-то. Т. е. куча всего, там 100 атрибутов.


Очень простой запрос делаем. Берем и группируем по Referer, считаем count, сортируем по count. И первые 10 результатов показываем.



Запрос нужно выполнить быстро. Как это сделать?


Во-первых, нужно очень быстро прочитать:


  • Самое простое, что тут надо сделать, это столбцовая организация. Т. е. храним данные по столбцам. Это нам позволит загрузить только нужные столбцы. В этом запросе это: ConterID, Date, Referrer. Как я уже сказал, их может быть 100. Естественно, если мы их все будем загружать, это все очень сильно нас затормозит.
  • Поскольку данные у нас в память, наверное, не помещаются, нам нужно читать локально. Конечно, мы не хотим читать всю таблицу, поэтому нам нужен индекс. Но даже если мы читаем эту маленькую часть, которая нам нужна, нам нужно локальное чтение. Мы не можем по диску прыгать и искать данные, которые нам нужны для выполнения запроса.
  • И обязательно нужно данные сжимать. Они в несколько раз сжимаются и пропускную способность диска очень сильно экономят.


И после того, как мы данные прочитали, нам нужно их очень быстро обработать. В ClickHouse много чего для этого делается:


  • Самое главное, что он их обрабатывает блоками. Что такое блок? Блок это небольшая часть таблицы, размером где-то в несколько тысяч строк. Почему это важно? Потому что ClickHouse это интерпретатор. Все знают, что интерпретаторы это очень медленно. Но если мы overhead размажем на несколько тысяч строк, то он будет незаметен. Зато это нам позволит применить SIMD инструкции. И для кэша процессора это очень хорошо, потому что если мы блок подняли в кэш, там его обрабатываем, то это будет гораздо быстрее, чем если он куда-то в память будет проваливаться.
  • И очень много низкоуровневых оптимизаций. Я про это не буду говорить.


Так же, как и в обычных классических БД мы выбираем, смотрим, какие условия будут в большинстве запросов. В нашей системе веб-аналитике, скорее всего, это будет счетчик. Хозяин счетчика будет приходить и смотреть отчеты. А также дата, т. е. он будет смотреть отчеты за какой-то период времени. Или, может быть, он за все время существования захочет посмотреть, поэтому такой индекс CounterID, Date.


Как мы можем проверить, что он подойдет? Сортируем таблицу по CounterID, Date и смотрим наши строки, которые нам нужны, они занимают вот такую небольшую область. Это значит, что индекс подойдет. Он будет сильно ускорять.


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



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


И когда у нас этот индекс есть, то при выполнении запроса, что мы делаем? Мы должны выбрать строки, которые нам могут пригодиться для выполнения запроса. В данном случае нам нужен счетчик 1234 и дата с 31 мая. А тут только есть запись на 23 мая. Это значит, что мы, начиная с этой даты, все должны прочитать. И до записи, счетчик которой начинается уже 1235. Получается, что мы будем читать немножко больше записей, чем нужно. И для аналитических задач, когда вам много нужно строк прочитать это не страшно. Но если вам нужна какая-то одна строка, то работать все будет не так хорошо. Чтобы найти одну строку, вам придется 8 000 прочитать.


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


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


Что тут важно? Key-Value сценарий будет плохо работать. У меня здесь светло-серым обозначено то, что мы прочитаем, и темно-серым то, что нам. И вполне может быть, что вам нужна будет одна строка, а вы прочитаете много.


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



Я сказал, что таблица упорядочена, но не рассказал, как это сделать. А нам очень хочется, чтобы данные, которые поступают в ClickHouse, тут же были доступны для отчетов. Т. е. после insert секунда прошла, и вы уже их видите в своих отчетах.


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


Как это сделать? В ClickHouse прилагается вот такое решение. Движок таблицы MergeTree. Идея примерно такая же, как у LSM дерева. Т. е. у нас есть небольшое количество упорядоченных кусочков. Если их становится много, то мы берем несколько кусочков и из них делаем один. Таким образом поддерживаем каждый раз небольшое количество.



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



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


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



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


У ClickHouse есть одна особенность. Слияние происходит только с кусками, которые были вставлены подряд. В нашем случае был кусок, которые объединяет вставки от M до N. И маленький кусочек, который мы вставили на предыдущем слайде, который был вставлен под номером N+1.



Мы берем их и сливаем. И получаем новый кусок М до N+1. Он упорядоченный.


Что тут важно? Этот процесс происходит в фоне. И за ним обязательно нужно следить, потому что, если там что-то пойдет не так, например, он замедлится или вы начнете слишком часто вставлять, и он не будет справляться, то рано или поздно все сломается.


Как это будет выглядеть в случае с ClickHouse? Когда у вас будет на партицию (партиция это месяц) 200 кусков, то у вас внезапно затормозятся вставки. Таким образом ClickHouse попробует дать возможность слияниям догнать вставки. А если уже будет 300 кусков, то он вам просто запретит вставлять, потому что иначе данные будет очень тяжело прочитать из множества кусков. Поэтому, если будете использовать ClickHouse, то обязательно это мониторьте. Настройте в ClickHouse экспорт метрик в Graphite. Это очень просто делается. И следите за количеством кусков в партиции. Если количество большое, то вам нужно обязательно разобраться с этим. Может быть, что-то с диском или вы начали очень сильно вставлять. И это нужно чинить.



Все хорошо. У нас есть сервер ClickHouse, все работает. Но иногда его может не хватать.


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

Что предлагает ClickHouse? Предлагает шардировать данные и использовать дистрибутивы таблицы.



Что это такое? Шардирование это понятно. У вас есть какая-то таблица. И вы ставите несколько компьютеров, и на каждом компьютере часть этих данных. У меня на картинке они в таблице local_table.


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


Что она делает? Вот пошел запрос в select from distributed_table. Она возьмет его и перепишет distributed_table на local_table. И дальше отправит на все шарды сразу же.



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



Вот такой забавный benchmark. Чуть больше миллиарда строк. Это данные о поездках нью-йоркского такси. Они в открытом доступе лежат. Можно самому попробовать.


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



Как теперь раскладывать данные по шардам?


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


Но, в принципе, distributed таблица и сама умеет это делать, хотя есть несколько нюансов.


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



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


Что тут важно? Ключ шардирования можно даже рандом взять. Это тоже будет работать. Единственное, если вы хотите делать сложные joins и хотите, чтобы у вас данные, которые для joins нужны, были на одном шарде, тогда вам нужно уже задумываться о ключе шардирования.



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


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



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


При этом может происходить три типа событий:


  • INSERT вставка в реплику
  • FETCH одна реплика скачала кусок с другой
  • MERGE реплика взяла несколько кусков и слила их в один

Как происходит вставка? Вставляем на любую реплику. Тут видно, что Реплика 1 не самая хорошая, но на нее все равно можно вставить. И информация о вставке записывается в ZooKeeper. Т. е. для того, чтобы у вас репликация работала, придется установить ZooKeeper.


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


Дальше нам нужно еще выполнять merge, т. е. сливать куски. Merge нужно выполнять согласовано, иначе наборы кусков разойдутся. Для этого одна реплика становится лидером. Не назовем мастером, потому что с мастером сразу идет ассоциация, что только туда можно вставлять, но это неправда. Т. е. у нас Реплика 2 лидер. Она решила, что эти куски надо помержить, записала это в ZooKeeper, остальные реплики об этом информацию получат и тоже сделают такой же merge.


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



И любое обсуждение репликации упирается в CAP-теорему, т. е. у вас есть какое-то место, где вы можете читать и писать, и вы его реплицируете, то в случае сетевого сбоя вам нужно сделать выбор: либо вы продолжаете читать и писать, либо вам все-таки нужны свежие данные правильные.


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


Доступность почти есть. Как сделать неубиваемый кластер ClickHouse? Берете три дата-центра. ZK в 3-х дата-центрах, а реплики, как минимум, в 2-х. И если у вас локация взрывается, то все продолжает работать и на чтение, и на запись.


Часто спрашивают: А как в двух дата-центрах сделать?. В двух не получится из-за ZooKeeper. Если у вас только две локации, то вы какой-то дата-центр объявляете главным. И если не главный отключается, то у вас все продолжает работать. Если главный отключаете, то у вас только на чтение.


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



Вот эти две фичи: distributed_table, replicated_table независимы. Их можно независимо использовать. Но они очень хорошо работают вместе. Нормальный кластер ClickHouse мы его примерно так себе представляем. Т. е. у нас есть N шардов и каждый трехкратно реплицирован. И distributed таблица умеет понимает, что шарды это реплики, могут отправлять запрос только в одну реплику шарда. И имеет отказоустойчивость, т. е. если у вас какая-то реплика недоступна, она в другую пойдет.


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



Что такое ClickHouse?


  • Это столбцовая column-oriented база данных, которая позволяет очень быстро выполнять аналитические и интерактивные запросы.
  • Язык запросов это SQL с расширениями.
  • Плохо подходит для OLTP, потому что транзакций нет. Key-Value, потому что у нас разреженный индекс. Если вам нужна одна строчка, то вы много чего лишнего прочитаете. И если у вас Key-Value с большими blob, то это вообще будет плохо работать.
  • Линейно масштабируется, если шардировать и использовать distributed таблицы.
  • Отказоустойчивая, если использовать replicate таблицы.
  • И все это в open source с очень активным community.


Вопросы


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


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



Вот эта вставка блоками. В ZK хранятся checksums последних ста блоков. Это тоже настраиваемо, но 100 неплохой вариант. Поэтому если вы вставили блок и у вас что-то взорвалось, и вы не уверены вставили вы или нет, то вставьте еще раз. Если вставка прошла, то ClickHouse это обнаружит и не будет дублировать данные.


Т. е. если мы вставляем по 10 000 строк, у нас там будет храниться миллион строк, которые будут гарантировано недублированными?


Нет. Дублирование работает не на уровне строк.


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


Да, но только если выставляете прямо такими же блоками.


Т. е. идентичными блоками, да?


Да, для идентичного блока считается checksum. Если checksum совпадает, значит блок уже вставили и дублировать не надо.


Я понял. И второй вопрос. Меня интересуют запросы distributed таблицы к replicated таблицам. Я так понимаю, что запрос у нас идет только к одной реплике. Можно ли как-то настроить, чтобы какие-то тяжелые запросы шли на обе реплики, чтобы часть данных оттуда, часть данных оттуда каким-то образом доставалась?


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


Не будет ли еще раз сэмплирование?


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


Понял, спасибо!


Спасибо за доклад! У меня три вопроса. Вы говорили, что индексы размазаны, т. е. там 8 000 с чем-то. И нужно писать большими объемами. Используете ли вы какую-то предбуферизацию? Рекомендуете ли вы что-то использовать?


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


Что есть? Есть буфер-таблица, куда тоже по одной строчке не надо вставлять, потому что будет тормозить на какой-то ерунде. Но если вы туда вставляете, она по диску меньше ездит. Т. е. не будет на каждую вставку делать запись на диск. И очень многие люди, которые уже более серьезно подходят к ClickHouse, они используют Kafka. У вас в Kafka lock, ваша писалка берет записи из Kafka и вставляет их в ClickHouse. Это тоже хороший вариант.


Да, т. е. можно это вручную настроить. Еще вопрос. У нас есть distributed таблица, которая управляет всеми шардами. И, например, шард с distributed таблицы умер. Это значит, что все данные у нас умерли?


Distributed таблица не хранит ничего. Если она у вас умерла, то вы просто создаете заново, и все так же работает. Главное, сохранить local_tables, в которых данные лежат, поэтому, конечно, их нужно реплицировать.


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


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


Т. е. я должен хранить это, куда я записал?


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


Спасибо большое!


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


Да, можно изменить целиком блок, точнее не блок, а всю партицию. Сейчас это месяц. Но у нас есть приоритетная задача сделать партицию произвольной. Вы берете и говорите alter table drop partition и он убирается, и вы можете обратно залить данные.


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


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


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


Мы все-таки рекомендуем replicated таблицы. Почему? Потому что distributed таблица тоже умеет реплицировать.


Как replicated сделать на два ДЦ? У меня все равно получается, что если падает мастер, то писать никуда нельзя, а можно только читать. Или там какие-то простые способы? Slave сделать мастером, а потом догнать первого мастера до slave?


А с Kafka у вас как?


С Kafka я буду выливать каждую независимо. С Kafka все равно придется делать на три ДЦ.


Kafka тоже использует ZK.


На нее данных меньше надо. Но она только пару дней будет хранить, а не за всю историю, в Kafka меньше ресурсов. Но ее на три ДЦ дешевле делать, чем ClickHouse на три ДЦ.


ClickHouse не обязательно размазывать на три, вам только нужно ZK поставить.


А, все, только для quorum ZK, данные дублируются только два раза. Для quorum у нас есть ДЦ.


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


У меня вопрос касается утилизации памяти. Как наиболее эффективно распределять ее? Сколько под instants выделять?


Про память такая история, что в ClickHouse есть такая настройка, как max_memory_usage. Это сколько вы можете отъесть, когда обрабатываете запрос. Для чего еще нужна память? Память нужна под дисковый кэш. Т. е. у ClickHouse нет какого-то хитрого кэша. Некоторые системы, как делают? Они читают o_direct с диска и как-то у себя кэшируют. ClickHouse так не делает. Какую-то часть памяти (довольно большую) нужно оставить под дисковый кэш. У вас данные, которые недавно читались с диска, будут потом из памяти прочитываться. И треть вы отводите на память, которая нужна в запросе.


Для чего ClickHouse расходует память? Если у вас запрос стриминговый, т. е. просто пройтись и что-то там посчитать, например, count, то будут единицы памяти расходоваться.


Где может понадобиться память? Когда у вас group by с большим количеством ключей. Например, вы по тем же самым referrers что-то группируете и у вас очень много различных referrers, urls. И все эти ключи нужно хранить. Если вам хватило памяти, то хорошо, а если не хватило, то есть возможность group by выполнить на диске, но это будет гораздо медленнее.


Это он сам определит?


Нужно включить.


Есть какой-то объем, который вы рекомендуете выстраивать? Например, 32 GB на ноду? Т. е., когда эффективно используется.


Чем больше, тем лучше. У нас 128 GB.


И один instance все 128 использует, да?


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


Алексей, спасибо за доклад! Вы не измеряли падение производительности при сильной фрагментации файловой системы?


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


Хотя бы примерный порядок?


Не знаю, процентов до 70 нормально будет.


Спасибо!


Добрый день! У меня два вопроса. Насколько я знаю, сейчас у ClickHouse только http-интерфейс для обмена данными с клиентом. А есть ли какой-то roadmap, чтобы сделать бинарный интерфейс?


У нас есть два интерфейса. Это http, который можно любым http-клиентом использовать, который в JDBC-драйвере используется. И есть нативный интерфейс, который мы всегда считали приватным и не хотели для него какой-то библиотеки делать. Но интерфейс этот не такой сложный. И мы поддерживаем там прямую-обратную совместимость, поэтому добрые люди использовали исходники как документацию и в Go есть, я слышал, отличный драйвер, которые нативные клиенты используют. И для C++ мой коллега сделал отдельный драйвер, который позволяет использовать нативный интерфейс и вам не нужно линковаться со всем ClickHouse, чтобы его использовать. И для других языков тоже, наверное, есть. Точно не знаю. Т. е. формально мы его считаем нашим приватным, но по факту он уже публичный. Из некоторых языков им можно пользоваться.


Спасибо! Вы говорили, что написали свою систему репликации данных. Допустим, Impala использует HDFS для репликации данных, она не делает репликацию самостоятельно. Почему вы написали репликацию, чем она лучше, чем HDFS?


Интересный вопрос. ClickHouse развивается послойно. Сначала были простые merge таблицы, потом появилась для них репликация. И вот эта схема с кусками, которая мержится, она просто так на HDFS не ложится. Наверное, можно было использовать HDFS как файловую систему и там хранить куски, но проще на локальной файловой системе это делать.


Т. е. вы напрямую не сравнивали?


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


Один кусок это будет один блок на HDFS и будет операция *opened*, если это возможно.


Т. е. использовать HDFS как хранилище?


Да. Чтобы не делать собственные репликации. Вы записали на HDFS и считайте, что оно уже реплицировано, и поддерживается отказоустойчивость.


А читать-то мы хотим с локального диска.


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


Интересная мысль, надо подумать.


Спасибо!

Подробнее..

Изучаем VoIP-движок Mediastreamer2. Часть 13, заключительная

01.07.2020 16:06:10 | Автор: admin

Материал статьи взят с моего дзен-канала.



В прошлой статье, мы рассмотрели вопросы отладки крафтовых фильтров, связанные с перемещением данных.


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


Что такое нагрузка на тикер


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


MS2_PUBLIC float ms_ticker_get_average_load(MSTicker *ticker);

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


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


struct _MSTickerLateEvent{int lateMs; /**<Запаздывание которое было в последний раз, в миллисекундах */uint64_t time; /**< Время возникновения события, в миллисекундах */int current_late_ms; /**< Запаздывание на текущем тике, в миллисекундах */};typedef struct _MSTickerLateEvent MSTickerLateEvent;

По которому в консоль выводится сообщение, которое выглядит примерно так:


ortp-warning-MSTicker: We are late of 164 miliseconds


С помощью функции


void ms_ticker_get_last_late_tick(MSTicker *ticker, MSTickerLateEvent *ev);

можно узнать подробности о последнем таком событии.


Способы снижения загрузки тикера


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


Изменение приоритета тикера


Приоритет тикера имеет три градации, которые определены в перечислении MSTickerPrio:


enum _MSTickerPrio{MS_TICKER_PRIO_NORMAL, /* Приоритет соответствующий значению по умолчанию для данной ОС. */MS_TICKER_PRIO_HIGH, /* Увеличенный приоритет устанавливается подlinux/MacOS с помощью setpriority() или sched_setschedparams() устанавливается политика SCHED_RR. */MS_TICKER_PRIO_REALTIME /* Наибольший приоритет, для него под Linux используется политика SCHED_FIFO. */};typedef enum _MSTickerPrio MSTickerPrio;

Чтобы поэкспериментировать с нагрузкой тикера, нам требуется схема, которая во время работы будет наращивать нагрузку и завершать работу когда нагрузка достигнет уровня 99%. В качестве нагрузки будем использовать схему:
ticker -> voidsource -> dtmfgen -> voidsink
Нагрузка будет увеличиваться добавлением между dtmfgen и voidsink нового элемента управления уровнем сигнала (тип фильтра MS_VOLUME), с коэффициентом передачи неравным единице, чтобы фильтр не филонил.
Она показана на рисунке

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


Файл mstest13.c Переменная вычислительная нагрузка.
/* Файл mstest13.c Переменная вычислительная нагрузка. */#include <stdio.h>#include <signal.h>#include <mediastreamer2/msfilter.h>#include <mediastreamer2/msticker.h>#include <mediastreamer2/dtmfgen.h>#include <mediastreamer2/mssndcard.h>#include <mediastreamer2/msvolume.h>/*----------------------------------------------------------*/struct _app_vars{    int  step;              /* Количество фильтров добавляемых за раз. */    int  limit;             /* Количество фильтров на котором закончить работу. */    int  ticker_priority;   /* Приоритет тикера. */    char* file_name;        /* Имя выходного файла. */    FILE *file;};typedef struct _app_vars app_vars;/*----------------------------------------------------------*//* Функция преобразования аргументов командной строки в* настройки программы. */void  scan_args(int argc, char *argv[], app_vars *v){    char i;    for (i=0; i<argc; i++)    {        if (!strcmp(argv[i], "--help"))        {            char *p=argv[0]; p=p + 2;            printf("  %s computational load\n\n", p);            printf("--help      List of options.\n");            printf("--version   Version of application.\n");            printf("--step      Filters count per step.\n");            printf("--tprio     Ticker priority:\n"                    "            MS_TICKER_PRIO_NORMAL   0\n"                    "            MS_TICKER_PRIO_HIGH     1\n"                    "            MS_TICKER_PRIO_REALTIME 2\n");            printf("--limit     Filters count limit.\n");            printf("-o          Output file name.\n");            exit(0);        }        if (!strcmp(argv[i], "--version"))        {            printf("0.1\n");            exit(0);        }        if (!strcmp(argv[i], "--step"))        {            v->step = atoi(argv[i+1]);            printf("step: %i\n", v->step);        }        if (!strcmp(argv[i], "--tprio"))        {            int prio = atoi(argv[i+1]);            if ((prio >=MS_TICKER_PRIO_NORMAL) && (prio <= MS_TICKER_PRIO_REALTIME))            {                v->ticker_priority = atoi(argv[i+1]);                printf("ticker priority: %i\n", v->ticker_priority);            }            else            {                printf(" Bad ticker priority: %i\n", prio);                exit(1);            }        }        if (!strcmp(argv[i], "--limit"))        {            v->limit = atoi(argv[i+1]);            printf("limit: %i\n", v->limit);        }        if (!strcmp(argv[i], "-o"))        {            v->file_name=argv[i+1];            printf("file namet: %s\n", v->file_name);        }    }}/*----------------------------------------------------------*//* Структура для хранения настроек программы. */app_vars vars;/*----------------------------------------------------------*/void saveMyData(){    // Закрываем файл.    if (vars.file) fclose(vars.file);    exit(0);}void signalHandler( int signalNumber ){    static pthread_once_t semaphore = PTHREAD_ONCE_INIT;    printf("\nsignal %i received.\n", signalNumber);    pthread_once( & semaphore, saveMyData );}/*----------------------------------------------------------*/int main(int argc, char *argv[]){    /* Устанавливаем настройки по умолчанию. */    app_vars vars={100, 100500, MS_TICKER_PRIO_NORMAL, 0};    // Подключаем обработчик Ctrl-C.    signal( SIGTERM, signalHandler );    signal( SIGINT,  signalHandler );    /* Устанавливаем настройки настройки программы в     * соответствии с аргументами командной строки. */    scan_args(argc, argv, &vars);    if (vars.file_name)    {        vars.file = fopen(vars.file_name, "w");    }    ms_init();    /* Создаем экземпляры фильтров. */    MSFilter  *voidsource=ms_filter_new(MS_VOID_SOURCE_ID);    MSFilter  *dtmfgen=ms_filter_new(MS_DTMF_GEN_ID);    MSSndCard *card_playback=ms_snd_card_manager_get_default_card(ms_snd_card_manager_get());    MSFilter  *snd_card_write=ms_snd_card_create_writer(card_playback);    MSFilter  *voidsink=ms_filter_new(MS_VOID_SINK_ID);    MSDtmfGenCustomTone dtmf_cfg;    /* Устанавливаем имя нашего сигнала, помня о том, что в массиве мы должны     * оставить место для нуля, который обозначает конец строки. */    strncpy(dtmf_cfg.tone_name, "busy", sizeof(dtmf_cfg.tone_name));    dtmf_cfg.duration=1000;    dtmf_cfg.frequencies[0]=440; /* Будем генерировать один тон, частоту второго тона установим в 0.*/    dtmf_cfg.frequencies[1]=0;    dtmf_cfg.amplitude=1.0; /* Такой амплитуде синуса должен соответствовать результат измерения 0.707.*/    dtmf_cfg.interval=0.;    dtmf_cfg.repeat_count=0.;    /* Задаем переменные для хранения результата */    float load=0.;    float latency=0.;    int filter_count=0;    /* Создаем тикер. */    MSTicker *ticker=ms_ticker_new();    ms_ticker_set_priority(ticker, vars.ticker_priority);    /* Соединяем фильтры в цепочку. */    ms_filter_link(voidsource, 0, dtmfgen, 0);    ms_filter_link(dtmfgen, 0, voidsink, 0);    MSFilter* previous_filter=dtmfgen;    int gain=1;    int i;    printf("# filters load\n");    if (vars.file)    {        fprintf(vars.file, "# filters load\n");    }    while ((load <= 99.) && (filter_count < vars.limit))    {        // Временно отключаем  "поглотитель" пакетов от схемы.        ms_filter_unlink(previous_filter, 0, voidsink, 0);        MSFilter  *volume;        for (i=0; i<vars.step; i++)        {            volume=ms_filter_new(MS_VOLUME_ID);            ms_filter_call_method(volume, MS_VOLUME_SET_DB_GAIN, &gain);            ms_filter_link(previous_filter, 0, volume, 0);            previous_filter = volume;        }        // Возвращаем "поглотитель" пакетов в схему.        ms_filter_link(volume, 0, voidsink, 0);        /* Подключаем источник тактов. */        ms_ticker_attach(ticker,voidsource);        /* Включаем звуковой генератор. */        ms_filter_call_method(dtmfgen, MS_DTMF_GEN_PLAY_CUSTOM, (void*)&dtmf_cfg);        /* Даем, время 100 миллисекунд, чтобы были накоплены данные для усреднения. */        ms_usleep(500000);        /* Читаем результат измерения. */        load=ms_ticker_get_average_load(ticker);        filter_count=filter_count + vars.step;        /* Отключаем источник тактов. */        ms_ticker_detach(ticker,voidsource);        printf("%i  %f\n", filter_count, load);        if (vars.file) fprintf(vars.file,"%i  %f\n", filter_count, load);    }    if (vars.file) fclose(vars.file);}

Сохраняем под именем mstest13.c и компилируем командой:


$ gcc mstest13.c -o mstest13 `pkg-config mediastreamer --libs --cflags`

Далее запускаем наш инструмент, чтобы оценить нагрузку тикера работающего с наименьшим приоритетом:


$ ./mstest13 --step 100  --limit 40000 -tprio 0 -o log0.txt

$ ./mstest13 --step 100  --limit 40000 -tprio 1 -o log1.txt

$ ./mstest13 --step 100  --limit 40000 -tprio 2 -o log2.txt

Далее "скармливаем" получившиеся файлы log0.txt, log1.txt, log2.txt великолепной утилите gnuplot:


$ gnuplot -e  "set terminal png; set output 'load.png'; plot 'log0.txt' using 1:2 with lines , 'log1.txt' using 1:2 with lines, 'log2.txt' using 1:2 with lines"

В результате работы программы будет создан файл load.png, в котором будет отрисован график имеющий следующий вид:

По вертикали отложена нагрузка тикера в процентах, по горизонтали количество добавленных фильтров нагрузки.
На этом графике мы видим, что как и ожидалось, для приоритета 2 (голубая линия), первый заметный выброс наблюдается при подключенных 6000 фильтрах, когда как для приоритетов 0 (фиолетовая) и 1(зеленая) выбросы появляются раньше, при 1000 и 3000 фильтров соответственно.


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


Перенос работы в другой тред


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


Интертикеры


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


Чтобы началась передача данных, эти фильтры нужно соединить, но не так как мы это делали с обычными фильтрами, т.е. функцией ms_filter_link(). В данном случае, используется метод MS_ITC_SINK_CONNECT фильтра MS_ITC_SINK:


ms_filter_call_method (itc_sink, MS_ITC_SINK_CONNECT, itc_src)

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


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


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


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

Соответствующий код программы показан ниже.


Файл mstest14.c Переменная вычислительная нагрузка c интертикерами
/* Файл mstest14.c Переменная вычислительная нагрузка c интертикерами. */#include <stdio.h>#include <signal.h>#include <mediastreamer2/msfilter.h>#include <mediastreamer2/msticker.h>#include <mediastreamer2/dtmfgen.h>#include <mediastreamer2/mssndcard.h>#include <mediastreamer2/msvolume.h>#include <mediastreamer2/msitc.h>/*----------------------------------------------------------*/struct _app_vars{    int  step;              /* Количество фильтров добавляемых за раз. */    int  limit;             /* Количество фильтров на котором закончить работу. */    int  ticker_priority;   /* Приоритет тикера. */    char* file_name;        /* Имя выходного файла. */    FILE *file;};typedef struct _app_vars app_vars;/*----------------------------------------------------------*//* Функция преобразования аргументов командной строки в  * настройки программы. */void  scan_args(int argc, char *argv[], app_vars *v){    char i;    for (i=0; i<argc; i++)    {        if (!strcmp(argv[i], "--help"))        {            char *p=argv[0]; p=p + 2;            printf("  %s computational load diveded for two threads.\n\n", p);            printf("--help      List of options.\n");            printf("--version   Version of application.\n");            printf("--step      Filters count per step.\n");            printf("--tprio     Ticker priority:\n"                    "            MS_TICKER_PRIO_NORMAL   0\n"                     "            MS_TICKER_PRIO_HIGH     1\n"                    "            MS_TICKER_PRIO_REALTIME 2\n");            printf("--limit     Filters count limit.\n");            printf("-o          Output file name.\n");            exit(0);        }        if (!strcmp(argv[i], "--version"))        {            printf("0.1\n");            exit(0);        }        if (!strcmp(argv[i], "--step"))        {            v->step = atoi(argv[i+1]);            printf("step: %i\n", v->step);        }        if (!strcmp(argv[i], "--tprio"))        {            int prio = atoi(argv[i+1]);            if ((prio >=MS_TICKER_PRIO_NORMAL) && (prio <= MS_TICKER_PRIO_REALTIME))            {                 v->ticker_priority = atoi(argv[i+1]);                printf("ticker priority: %i\n", v->ticker_priority);            }            else            {                printf(" Bad ticker priority: %i\n", prio);                exit(1);            }        }        if (!strcmp(argv[i], "--limit"))        {            v->limit = atoi(argv[i+1]);            printf("limit: %i\n", v->limit);        }        if (!strcmp(argv[i], "-o"))        {            v->file_name=argv[i+1];            printf("file namet: %s\n", v->file_name);        }    }}/*----------------------------------------------------------*//* Структура для хранения настроек программы. */app_vars vars;/*----------------------------------------------------------*/void saveMyData(){    // Закрываем файл.    if (vars.file) fclose(vars.file);    exit(0);}void signalHandler( int signalNumber ){    static pthread_once_t semaphore = PTHREAD_ONCE_INIT;    printf("\nsignal %i received.\n", signalNumber);    pthread_once( & semaphore, saveMyData );}/*----------------------------------------------------------*/int main(int argc, char *argv[]){    /* Устанавливаем настройки по умолчанию. */    app_vars vars={100, 100500, MS_TICKER_PRIO_NORMAL, 0};    // Подключаем обработчик Ctrl-C.    signal( SIGTERM, signalHandler );    signal( SIGINT,  signalHandler );    /* Устанавливаем настройки настройки программы в      * соответствии с аргументами командной строки. */    scan_args(argc, argv, &vars);    if (vars.file_name)    {        vars.file = fopen(vars.file_name, "w");    }    ms_init();    /* Создаем экземпляры фильтров для первого треда. */    MSFilter  *voidsource = ms_filter_new(MS_VOID_SOURCE_ID);    MSFilter  *dtmfgen    = ms_filter_new(MS_DTMF_GEN_ID);    MSFilter  *itc_sink   = ms_filter_new(MS_ITC_SINK_ID);    MSDtmfGenCustomTone dtmf_cfg;    /* Устанавливаем имя нашего сигнала, помня о том, что в массиве мы должны     * оставить место для нуля, который обозначает конец строки. */    strncpy(dtmf_cfg.tone_name, "busy", sizeof(dtmf_cfg.tone_name));    dtmf_cfg.duration=1000;    dtmf_cfg.frequencies[0]=440; /* Будем генерировать один тон, частоту второго тона установим в 0.*/    dtmf_cfg.frequencies[1]=0;    dtmf_cfg.amplitude=1.0; /* Такой амплитуде синуса должен соответствовать результат измерения 0.707.*/    dtmf_cfg.interval=0.;    dtmf_cfg.repeat_count=0.;    /* Задаем переменные для хранения результата */    float load=0.;    float latency=0.;    int filter_count=0;    /* Создаем тикер. */    MSTicker *ticker1=ms_ticker_new();    ms_ticker_set_priority(ticker1, vars.ticker_priority);    /* Соединяем фильтры в цепочку. */    ms_filter_link(voidsource, 0, dtmfgen, 0);    ms_filter_link(dtmfgen, 0, itc_sink , 0);    /* Создаем экземпляры фильтров для второго треда. */    MSTicker *ticker2=ms_ticker_new();    ms_ticker_set_priority(ticker2, vars.ticker_priority);    MSFilter *itc_src   = ms_filter_new(MS_ITC_SOURCE_ID);    MSFilter *voidsink2 = ms_filter_new(MS_VOID_SINK_ID);    ms_filter_call_method (itc_sink, MS_ITC_SINK_CONNECT, itc_src);    ms_filter_link(itc_src, 0, voidsink2, 0);    MSFilter* previous_filter1=dtmfgen;    MSFilter* previous_filter2=itc_src;    int gain=1;    int i;    printf("# filters load\n");    if (vars.file)    {        fprintf(vars.file, "# filters load\n");    }    while ((load <= 99.) && (filter_count < vars.limit))    {        // Временно отключаем  "поглотители" пакетов от схем.        ms_filter_unlink(previous_filter1, 0, itc_sink, 0);        ms_filter_unlink(previous_filter2, 0, voidsink2, 0);        MSFilter  *volume1, *volume2;        // Делим новые фильтры нагрузки между двумя тредами.        int new_filters = vars.step>>1;        for (i=0; i < new_filters; i++)        {            volume1=ms_filter_new(MS_VOLUME_ID);            ms_filter_call_method(volume1, MS_VOLUME_SET_DB_GAIN, &gain);            ms_filter_link(previous_filter1, 0, volume1, 0);            previous_filter1 = volume1;        }        new_filters = vars.step - new_filters;        for (i=0; i < new_filters; i++)        {            volume2=ms_filter_new(MS_VOLUME_ID);            ms_filter_call_method(volume2, MS_VOLUME_SET_DB_GAIN, &gain);            ms_filter_link(previous_filter2, 0, volume2, 0);            previous_filter2 = volume2;        }        // Возвращаем "поглотители" пакетов в схемы.        ms_filter_link(volume1, 0, itc_sink, 0);        ms_filter_link(volume2, 0, voidsink2, 0);        /* Подключаем источник тактов. */        ms_ticker_attach(ticker2, itc_src);        ms_ticker_attach(ticker1, voidsource);        /* Включаем звуковой генератор. */        ms_filter_call_method(dtmfgen, MS_DTMF_GEN_PLAY_CUSTOM, (void*)&dtmf_cfg);        /* Даем, время, чтобы были накоплены данные для усреднения. */        ms_usleep(500000);        /* Читаем результат измерения. */        load=ms_ticker_get_average_load(ticker1);        filter_count=filter_count + vars.step;        /* Отключаем источник тактов. */        ms_ticker_detach(ticker1, voidsource);        printf("%i  %f\n", filter_count, load);        if (vars.file) fprintf(vars.file,"%i  %f\n", filter_count, load);    }    if (vars.file) fclose(vars.file);}

Далее компилируем и запускаем нашу программу с тикерами, работающими с наименьшим приоритетом:


$ ./mstest14 --step 100  --limit 40000 -tprio 0 -o log4.txt

Результат измерений получится следующий:



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


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


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


Заключение


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

Подробнее..

FOSS News 22 обзор новостей свободного и открытого ПО за 22-28 июня 2020 года

28.06.2020 20:20:26 | Автор: admin


Всем привет!

Продолжаем обзоры новостей свободного и открытого ПО и немного железа. Всё самое главное про пингвинов и не только, в России и мире. Новый суперкомпьютер на первом месте в TOP-500 на ARM и Red Hat Enterprise Linux, два новых ноутбука на GNU/Linux, поддержка российских процессоров в ядре Linux, обсуждение системы голосования разработанной ДИТ Москвы, весьма дискуссионный материал о смерти двойной загрузки и о единстве Windows и Linux и многое другое.

Оглавление



  1. Главные новости
    1. Рейтинг самых высокопроизводительных суперкомпьютеров возглавил кластер на базе CPU ARM и с Red Hat Enterprise Linux
    2. Начались продажи сверхмощного ноутбука на Linux Ubuntu
    3. Представлен ноутбук Dell XPS 13 Developer Edition с предустановленным Ubuntu 20.04
    4. В ядро Linux добавлена поддержка российских процессоров Baikal T1
    5. Обсуждение системы голосования, разработанной ДИТ Москвы и выложенной в открытый доступ
    6. О смерти двойной загрузки и о единстве Windows и Linux (но это не точно)
  2. Короткой строкой
    1. Новости FOSS организаций
    2. Ядро и дистрибутивы
    3. Системное
    4. Специальное
    5. Безопасность
    6. Для разработчиков
    7. Пользовательское
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. Для разработчиков
    4. Специальный софт


Главные новости



Рейтинг самых высокопроизводительных суперкомпьютеров возглавил кластер на базе CPU ARM и с Red Hat Enterprise Linux





OpenNET пишет: Опубликован 55-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. Июньский рейтинг возглавил новый лидер японский кластер Fugaku, примечательный использованием процессоров ARM. Кластер Fugaku размещён в Институте физико-химических исследований RIKEN и обеспечивает производительность 415.5 петафлопс, что в 2.8 больше, чем вытесненный на второе место лидер прошлого рейтинга. Кластер включает 158976 узлов на базе SoC Fujitsu A64FX, оснащённых 48-ядерным CPU Armv8.2-A SVE (512 bit SIMD) с тактовой частотой 2.2GHz. В сумме кластер насчитывает более 7 млн процессорных ядер (в три раза больше, чем у лидера прошлого рейтинга), почти 5 ПБ ОЗУ и 150 ПБ общего хранилища на базе ФС Lustre. В качестве операционной системы используется Red Hat Enterprise Linux.

Подробности

Начались продажи сверхмощного ноутбука на Linux Ubuntu





CNews пишет: Производитель Linux-компьютеров System76 выпустил новый ноутбук Oryx Pro, способный запустить любую современную игру на максимальных настройках графики. При его покупке можно сконфигурировать почти любой его компонент и даже выбрать между ОС Linux Ubuntu и ее модифицированной версией Pop!_OS. В базовой комплектации Oryx Pro стоит $1623 (112,5 тыс. руб. по курсу ЦБ на 26 июня 2020 г.). Тогда как самая дорогая версия стоит $4959 (340 тыс. руб.).

Для Oryx Pro, по данным издания, есть варианты диагонали 15,6 и 17,3 дюймов. Используется процессор Intel Core i7-10875H, он располагает восемью ядрами с возможностью обработки 16 одновременных потоков данных и работает на частоте от 2,3 до 5,1 ГГц. Доступны варианты конфигурации оперативной памяти от 8 ГБ до 64 ГБ. По умолчанию ноутбук поставляется с графическим чипом Nvidia GeForce RTX 2060 и 6 ГБ собственной памяти стандарта GDDR6. Его можно заменить на RTX 2070 или RTX 2080 Super с 8 ГБ GDDR6.

Подробности

Представлен ноутбук Dell XPS 13 Developer Edition с предустановленным Ubuntu 20.04





OpenNET пишет: Компания Dell начала предустановку дистрибутива Ubuntu 20.04 на модель ноутбука XPS 13 Developer Edition, скомпонованного с оглядкой на применение в повседневной деятельности разработчиков программного обеспечения. Dell XPS 13 оснащён 13,4-дюймовым экраном Corning Gorilla Glass 6 19201200 (возможна замена на сенсорный экран InfinityEdge 38402400), процессором 10 Gen Intel Core i5-1035G1 (4 ядра, 6 Мб кэш, 3,6 ГГц), 8 Гб ОЗУ, SSD размером от 256 Гб до 2 Тб. Вес устройства 1,2 кг, время автономной работы до 18 часов. Серия Developer Edition развивается с 2012 года и предлагается с предустановленным Ubuntu Linux, протестированным для полной поддержки всех аппаратных компонентов устройства. Вместо ранее предлагаемого выпуска Ubuntu 18.04 модель теперь будет комплектоваться Ubuntu 20.04.

Подробности

Источник изображения

В ядро Linux добавлена поддержка российских процессоров Baikal T1





OpenNET пишет: Компания Baikal Electronics объявила о принятии в основной состав ядра Linux кода для поддержки российского процессора Baikal-T1 и основанной на нём системы на кристалле BE-T1000. Изменения с реализацией поддержки Baikal-T1 были переданы разработчикам ядра в конце мая и теперь включены в состав экспериментального выпуска ядра Linux 5.8-rc2. Рецензирование части изменений, в том числе описаний device tree, пока не завершено и данные изменения отложены для включения в ядро 5.9.

Подробности 1, 2

Обсуждение системы голосования, разработанной ДИТ Москвы и выложенной в открытый доступ





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

Подробности:
  1. Обсуждение системы голосования, разработанной ДИТ Москвы
  2. Требования по контролю за электронным голосованием


Источник изображения

О смерти двойной загрузки и о единстве Windows и Linux (но это не точно)





Весьма дискуссионный материал вышел на Хабре. Автор решил отказаться от продукции Apple из-за нежелания зависеть от одного вендора. Выбрал Ubuntu, иногда перезагружался в Windows для решения специфических задач. После появления WSL попробовал использовать Ubuntu не как отдельную установку, а в рамках Windows и остался доволен. Призывает последовать его примеру. Выбор конечно за каждым, а под статьей уже 480 комментариев, можно запасаться попкорном.

Подробности

Короткой строкой



Новости FOSS организаций


  1. Много eBook-ов, контейнеры Jenkins, Tekton Pipelines и 6 уроков по Istio Service Mesh. Полезные ссылки на живые мероприятия, видео, митапы и техтолки от RedHat []


Ядро и дистрибутивы


  1. Поддержка CPU AMD EPYC Rome перенесена во все актуальные выпуски Ubuntu Server []
  2. В Fedora намерены по умолчанию использовать текстовый редактор nano вместо vi []


Системное


  1. Vulkan-драйвер RADV переведён на использование бэкенда компиляции шейдеров ACO []


Специальное


  1. VPN WireGuard принят в основной состав OpenBSD []
  2. Собираем логи с Loki []
  3. Учебник по симулятору сети ns-3 теперь одним pdf-файлом []


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


  1. Microsoft выпустил редакцию пакета Defender ATP для Linux []
  2. Уязвимость в защищённом браузере Bitdefender SafePay, приводящая к выполнению кода []
  3. Компания Mozilla представила третьего провайдера DNS-over-HTTPS для Firefox []
  4. Уязвимость в UEFI для процессоров AMD, позволяющая выполнить код на уровне SMM []


Для разработчиков


  1. Bitbucket напоминает о скором удалении репозиториев Mercurial и уходит от слова Master в Git []
  2. Анонсирован Perl 7 []
  3. Лучшие 10 ресурсов для бесплатного изучения разработки shell скриптов по версии It's FOSS [ (en)]
  4. Открытые датасеты для automotive []
  5. Не хочу Visual Studio Code: 7 open source альтернатив []
  6. Как создать свой первый open source проект на Python (17 шагов) []
  7. Говорим и показываем: как мы создали сервис синхронного просмотра видео ITSkino на основе VLC []
  8. Flutter и настольные приложения []
  9. Использование секретов Kubernetes в конфигурациях Kafka Connect []
  10. Язык программирования Mash []
  11. Установка и настройка LXD на OpenNebula []
  12. Управление несколькими JDK в Mac OS, Linux и Windows WSL2 []


Пользовательское


  1. Jitsi Meet: свободное и открытое решение для проведения видеоконференций, которое ещё и можно использовать без какой-либо настройки [ (en)]
  2. Как отключить док в Ubuntu 20.04 и получить больше места на экране [ (en)]
  3. Горячие клавиши терминала GNU/Linux []
  4. Команда ps в Linux []
  5. Список процессов в Linux []


Релизы



Ядро и дистрибутивы


  1. Функциональность и стиль: выпущена новая версия Альт Рабочая станция К 9 []
  2. Вышел Calculate Linux 20.6 []
  3. Выпуск Live-дистрибутива Grml 2020.06 []
  4. Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux []
  5. Вышел Linux Mint 20 Ulyana []


Системный софт


  1. Релиз системы самодостаточных пакетов Flatpak 1.8.0 []
  2. Выпуск глобальной децентрализованной файловой системы IPFS 0.6 []
  3. Обновление проприетарных драйверов NVIDIA 440.100 и 390.138 с устранением уязвимостей []
  4. Для старых плат Raspberry Pi подготовлен GPU-драйвер с поддержкой API Vulkan []


Для разработчиков


  1. Релиз статического анализатора cppcheck 2.1 []
  2. Обновление редактора кода CudaText 1.105.5 []
  3. Релиз языка программирования Perl 5.32.0 []
  4. Выпуск Snuffleupagus 0.5.1, модуля для блокирования уязвимостей в PHP-приложениях []


Специальный софт


  1. Релиз минималистичного набора системных утилит BusyBox 1.32 []
  2. Выпуск curl 7.71.0 с устранением двух уязвимостей []
  3. Reddit-like агрегатор ссылок Lemmy 0.7.0 []
  4. Стабильный выпуск СУБД MariaDB 10.5 []
  5. Первый стабильный выпуск графо-ориентированной СУБД Nebula Graph []
  6. Выпуск Python-библиотеки для научных вычислений NumPy 1.19 []
  7. Выпуск SciPy 1.5.0, библиотеки для научных и инженерных расчётов []
  8. Выпуск PhotoGIMP 2020, модификации GIMP, стилизованной под Photoshop []
  9. Очередной релиз QVGE 0.5.5 (визуальный редактор графов) []





На этом всё, до следующего воскресенья!

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

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

Подписывайтесь на наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News.

Предыдущий выпуск
Подробнее..

FOSS News 23 обзор новостей свободного и открытого ПО за 29 июня 5 июля 2020 года

05.07.2020 18:06:24 | Автор: admin


Всем привет!

Продолжаем обзоры новостей свободного и открытого ПО и немного железа. Всё самое главное про пингвинов и не только, в России и мире. Линус Торвальдс о будущем разработки ядра Linux, один из интернет-гигантов Baidu присоединился к защите Linux от патентных претензий, исторический материал об одном из создателей UNIX и C Денниса Ритчи, софтверные санкции США в отношении России, эксперимент по crowd-source разработке Конституции и многое другое.

Оглавление


  1. Главные новости
    1. Линус Торвальдс о будущем разработки ядра Linux
    2. Baidu присоединился к инициативе по защите Linux от патентных претензий
    3. Утерянная диссертация Денниса Ритчи
    4. США запретили продавать Windows и iPhone российским военным и полиции
    5. Альтернативная конституция
  2. Короткой строкой
    1. Новости FOSS организаций
    2. Ядро и дистрибутивы
    3. Системное
    4. Специальное
    5. Безопасность
    6. Для разработчиков
    7. Пользовательское
    8. Разное
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. Для разработчиков
    4. Специальный софт
    5. Игры
    6. Пользовательский софт

Главные новости


Линус Торвальдс о будущем разработки ядра Linux




Создатель Linux Линус Торвальдс рассказал о проблеме поиска будущих сопровождающих для операционной системы с открытым исходным кодом, пишут в новости на Хабре: Это случилось на виртуальной конференции Open Source Summit и Embedded Linux, проходящей на этой неделе. Торвальдс пообщался с руководителем VMware Дирком Хонделом. Он заявил: Я сказал, что ядро Linux скучное, но я имею в виду, что многие новые технологии должны быть более интересными. Для меня и многих других людей нет ничего более интересного, чем взаимодействие на низком уровне с оборудованием для реального контроля того, что происходит.

Подробности:

  1. Краткая новость
  2. Больше подробностей (en)

Baidu присоединился к инициативе по защите Linux от патентных претензий




Китайская компания Baidu, входящая в число крупнейших мировых производителей интернет-сервисов и продуктов, связанных с искусственным интеллектом, вошла в число участников организации Open Invention Network (OIN), занимающейся защитой экосистемы Linux от патентных претензий, пишет OpenNET. В число участников OIN входит более 3200 компаний, сообществ и организаций, подписавших лицензионное соглашение о совместном использовании патентов. Среди основных участников OIN, обеспечивающих формирование защищающего Linux патентного пула, такие компании, как Google, IBM, NEC, Toyota, Renault, SUSE, Philips, Red Hat, Alibaba, HP, AT&T, Juniper, Facebook, Cisco, Casio, Huawei, Fujitsu, Sony и Microsoft. Подписавшие соглашение компании получают доступ к имеющимся в руках OIN патентам, в обмен на обязательство не предъявлять судебных претензий за использование технологий, применяемых в экосистеме Linux дополняет издание.

Подробности

Утерянная диссертация Денниса Ритчи




Перевод интересной исторической статьи вышел на Хабре о предыстории работы Денниса Ритчи, одного из основателей UNIX и языка C, то есть двух технологий, на которых, можно без преувеличения сказать, держится весь современный компьютерный мир. Я получил степень бакалавра и учёную степень в Университете Гарварда, где студентом занимался физикой, а аспирантом прикладной математикой Темой моей докторской диссертации 1968 года были подрекурсивные иерархии функций. Опыт моей студенческой учёбы убедил меня, что я недостаточно умён для физика, и что компьютеры это довольно любопытно. Мой аспирантский опыт убедил меня, что я недостаточно умён, чтобы стать специалистом в теории алгоритмов, и что мне больше нравятся процедурные, а не функциональные языки после такого весьма критического самоанализа Ритчи встал на путь, приведший его к великим делам.

Подробности

США запретили продавать Windows и iPhone российским военным и полиции





Не совсем по теме обзоров, но тем не менее интересная новость и всё-таки имеющая определённую связь с нашими интересами. Оставив за скобками разбор отношений США и России, посмотрим сухо на факты и на отношение случившегося к FOSS. На Хабре со ссылкой на РБК пишут: США в очередной раз ужесточили правила экспортного контроля в отношении поставок товаров в Россию. 29 июня вступили в силу два новых правила. Первое правило отменяет исключение для американских экспортеров, которые до этого могли поставлять в Россию без лицензии относительно широкий спектр товаров, если они предназначены для гражданского использования гражданскими потребителями. Теперь, даже если эти товары предполагается использовать исключительно в гражданских целях, экспортеру понадобится получить специальную лицензию Минторга США. Второе правило, затрагивающее Россию, Китай и Венесуэлу, расширяет определение военного использования товаров, что сузит и без того минимальные возможности российского оборонного сектора закупать американские товары, технологии и программное обеспечение. В блоге международной юрфирмы Pillsbury Winthrop Shaw Pittman отмечается, что по новым правилам в перечень подобных товаров отныне входят iPhone и копии Microsoft Windows, а также, что их продажа военным пользователям станет практически невозможна.

Глядя на новости, неоднократно упомянутые в прошлых обзорах, военные и полиция уже и так активно переходят на софт, основанный на FOSS-разработках (вспомним хотя бы массовые закупки Astra Linux силовиками, упомянутые в 0-м обзоре vk.com/@permlug-foss-news-0). Происходящее ярко показывает, что даже казалось бы частные и далёкие от политики разработки при необходимости легко используются в противостоянии на политическом уровне, которое, впрочем, весьма часто имеет совершенно экономические основания. Принципиально не могущие иметь подобных ограничений развитые FOSS-решения, естественно, начинают набирать популярность. Конечно, встают вопросы отдачи FOSS-проектам от этого использования и соответствия ценностей тех, кто разрабатывал FOSS софт, и тех, кто становится всё более активным его пользователем. Но свободное ПО на то и свободное, что никто не имеет права судить и решать, кому можно пользоваться разработками, сделанными практически всем миром, а кому нельзя.

Подробности

Альтернативная конституция




Интересный эксперимент предложен на Хабре, делающий попытку перенести в юридическую плоскость принципы из IT и, более конкретно, FOSS его части. Автор статьи пишет: Этот пост я задумываю как рискованный эксперимент. Я хочу выяснить, могут ли ИТишники самоорганизоваться для создания открытого, свободного (от слова freedom, а не free beer), чистого, высококлассного кода, используя привычные им инструменты (Git, fork, TDD, agile, stackoverflow, абстракции, юнит-тесты и прочее). Только этот код это текст, который мог бы являться конституцией в альтернативной реальности (или фантастического рассказа), очень близкой к нашей. Если тебе не нравится чужой код напиши свой.

Подробности

Короткой строкой


Новости FOSS организаций


  1. Наши уникальные бесплатные мастер-курсы Kubernetes, CLI tool для разработчиков Odo, Java в контейнерах и много книг. Полезные ссылки на живые мероприятия, видео, митапы и техтолки от RedHat []
  2. Создатель СУБД Redis передал сопровождение проекта сообществу []
  3. Некоммерческий провайдер FossHost, предоставляющий хостинг свободным проектам []

Ядро и дистрибутивы


  1. Google работает над поддержкой Steam в Chrome OS через виртуальную машину с Ubuntu (проект Borealis) [ 1, 2, 3 (en)]
  2. Rolling Rhino, скрипт для использования rolling-обновлений в Ubuntu []
  3. Оценка изменений в выборе оборудования пользователями Linux в России за 2015-2020 годы []
  4. Бывший разработчик Solus теперь создаёт по-настоящему современный Linux дистрибутив Serpent (именно Linux а не GNU/Linux так как компоненты GNU в систему не будут включены) [ (en)]
  5. 13 вещей, которые нужно сделать после установки Linux Mint 20 [ (en)]
  6. Что означает окончание поддержки Ubuntu? Всё что нужно знать об этом [ (en)]

Системное


  1. В Firefox добавлено ускорение декодирования видео через VA-API для систем X11 []
  2. В Fedora рассматривают возможность прекращения поддержки BIOS при загрузке []
  3. Проект KDE завершил первую фазу миграции на GitLab []

Специальное


  1. От стартапа до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры []
  2. Основы Ansible, без которых ваши плейбуки комок слипшихся макарон []
  3. Почему в Docker не работает Strace []
  4. 5 современных альтернатив старым инструментам командной строки Linux []
  5. Размещаем сайт на домашнем роутере []
  6. Использование Docker для чайников []
  7. XFS, Reflink и Fast Clone. Созданы друг для друга []
  8. Бесплатный minecraft сервер на AWS с нулевым знанием Linux []
  9. Опыт эксплуатации CEPH []
  10. Ликбез: главные компоненты встраиваемой (впрочем, не только) GNU/Linux системы [ (en)]
  11. Изучаем VoIP-движок Mediastreamer2. Часть 13, заключительная []
  12. Интеграция Open vSwitch с Р-виртуализацией []
  13. Лабаем на MIDI-клавиатуре в Angular []
  14. Удаляем устаревшую feature branch в Kubernetes кластере []
  15. DNS Push-уведомления получили статус предложенного стандарта []
  16. Как создать диаграмму Парето (правило 80/20) в LibreOffice Calc [ (en)]
  17. Как сделать прозрачный фон в GIMP [ (en)]
  18. Как обрезать изображения в GIMP [ (en)]

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


  1. Chrome, Firefox и Safari ограничат время жизни TLS-сертификатов 13 месяцами []
  2. В Ubuntu 20.10 будет ограничен доступ к dmesg []
  3. Найдена причина проблем dehydrated с ACME-серверами, отличными от LetsEncrypt []
  4. Анализ миллиарда учётных записей, полученных в результате различных утечек баз пользователей []

Для разработчиков


  1. Гвидо ван Россум предложил включить в Python операторы для сопоставления с образцом (подобие switch/match) []
  2. Godot, 1000 мелочей (об игровом движке) []
  3. Ищем фильмы, книги и подкасты с помощью Python []
  4. Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать. Алексей Зателепин (2018г) []
  5. Сущности для платформы Яндекс.Диалоги []
  6. Анализ рисков при воплощении в жизнь инициативы Perl 7 []

Пользовательское


  1. Каталог приложений на сайте KDE.org теперь доступен на русском языке []
  2. Как решить проблему no space left on device в Linux []
  3. Что за процесс kworker в Linux []

Разное


  1. Ультрабезопасный ноутбук от проекта Purism доступен с новой диагональю [ 1 (en), 2]
  2. Крошечный компьютер NanoPi NEO3 поможет создать сетевое хранилище данных []
  3. MIT удалил коллекцию Tiny Images из-за выявления расистских и женоненавистнических терминов []

Релизы


Ядро и дистрибутивы


  1. Релиз-кандидат Альт Образование 9.1 []
  2. Обновление дистрибутива Elementary OS 5.1.6 []
  3. Выпуск дистрибутива GParted Live 1.1.0-3 []
  4. Релиз дистрибутива openSUSE Leap 15.2 www.opennet.ru/opennews/art.shtml?num=53234, itsfoss.com/opensuse-leap-15-2-release (en), www.linux.org.ru/news/novell/15790801
  5. Релиз дистрибутива Tails 4.8 и Tor Browser 9.5.1 []

Системный софт


  1. Выпуск Wine 5.12 и Wine staging 5.12 []
  2. Релиз универсального генератора данных для панелей состояния luastatus v0.5.0 []

Для разработчиков


  1. Выпуск Psalm 3.12, статического анализатора для языка PHP. Альфа выпуск PHP 8.0 []
  2. Выпуск платформы динамической трассировки приложений Frida 12.10 []
  3. Релиз языка программирования Lua 5.4 [ 1, 2]

Специальный софт


  1. Что нового в Harbor 2.0? [ (en)]
  2. Большой релиз LanguageTool 5.0! []
  3. Выпуск Podman 2.0 []
  4. Выпуск видеоредактора Shotcut 20.06 [ 1, 2]

Игры


  1. Новая версия стратегической игры Warzone 2100. Проект OpenDiablo2 []
  2. Доступен набор классических текстовых игр bsd-games 3.0 []

Пользовательский софт


  1. Релизы Firefox 78 и 78.0.1, обновление голосовых данных Mozilla Common Voice [ 1, 2]
  2. Релиз свободной системы финансового учета GnuCash 4.0 [ 1, 2]



На этом всё, до следующего воскресенья!

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

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

Подписывайтесь на наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News.

Также вам может быть интересен новый релиз близкого нам обзора от единомышленников Linux новости #16. Blender, Krita, Vivaldi, PaleMoon, Brave, Linux Mint и Snap.

Предыдущий выпуск
Подробнее..

Играем в Бога, причиняем непрошеную помощь науке и немножечко Сингулярности

29.06.2020 18:10:05 | Автор: admin
Если вы хотя бы на пол шишечки интересуетесь современной наукой, то знаете кто такой Марков. Лауреат премии Просветитель, реально просветитель, автор кучи прекрасных книг, и афигенных роликов на ютубе, а ещё основной двигатель сайта elementy.ru, отличающегося тем, что статьи готовят профессионалы, а не журналисты, со ссылками на первоисточники и никогда никакого хайпа, что очень хорошо для мозговой гигиены. В общем он не только изучает увеличение мозга хомосапиенсов, но и реально его наполняет всяким интересным.



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

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

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

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

Часть первая, про Оптимизацию.


Make it work, Make it right, Make it fast! Kent Beck
Автором симулятора был сын нашего учителя Михаил JellicleFencer Марков. В комментариях под статьей он выложил ссылку на репозиторий: jelliclefencer.visualstudio.com/_git/TribeSim. Написать то он её написал, причём так чтобы происходящее внутри было понятно любому биологу без комментариев. Но времени на то чтобы заниматься оптимизацией у него явно не было. В результате залезши внутрь я в порядке хобби ускорил работу симуляции в 10-20 раз даже не прибегая к unsafe коду и прочим излишествам и потрогав пока только половину тормозящих мест. Читаемость снизилась, надеюсь, не критично. Азур меня почему-то не любит, поэтому я форкнулся на гитхаб вот сюда: github.com/kraidiky/TribeSim и там можно по коммитам проследить как я отъедал в куче мест по 5-15% прироста.

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

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

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

Есть ещё одно занятие, которое я давно хочу: стримы с разбором кода. Это как транслировать свои игры в твиче, только с аудиторией в 1000 раз меньше. :)))


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

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

Часть вторая, про Биологию.


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

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

Я хотел тут расписать значение всяких параметров модели, но это длинно и не очень интересно. Вместо этого поставьте брейкпоинт в функции World.SimulateYear, загрузите trsim allFeatures и пройдите один год симуляции по шагам. Сразу поймёте что там к чему и зачем.

Часть третья, про Мечты.



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

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

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

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

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

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

Часть третья, про Сингулярность.


Сам Александр Владимирович оговаривается, что в их модели не получилось увидеть стремительного гиперболического разгона мощности культуры, свойственного истории человечества. Также он упомянул, что есть идея поискать условия такого роста в виде комплексов взаимно усиливающих друг друга мемов. У меня же есть несколько иное предположение. Посмотреть про сингулярность можно очень меня вдохновившее выступление Панова на GF2045. А с ещё более скептическим взглядом ознакомиться в паре статьей Сергея Карелова "Техносингулярность становится технорелигией" и её второй части.

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

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

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

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

Заключение:


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

Ищем фильмы, книги и подкасты с помощью Python

02.07.2020 12:23:15 | Автор: admin

Пакет podsearch для поиска подкастов


Apple неособо афиширует, что у iTunes Store идругих каталогов есть кривенькое, нопростое поисковое API поэтому ярешил онём написать. Изэтой заметки выузнаете, что API умеет икак его использовать.


Поиск в каталогах Apple


API ищет посодержимому iTunes Store, iBooks Store, Apple Podcasts и App Store. Соответственно, можно найти песни, фильмы, книги, подкасты и приложения.


API работает подавно забытому принципу JSONP, тоесть возвращает Content-Type: text/javascript вместо нормального application/json.


GET /search?media=podcast&term=python HTTP/1.1Host: itunes.apple.comAccept: application/jsonHTTP/2 200content-type: text/javascript; charset=utf-8{...}

Конечно, эту особенность можно просто игнорировать:


import requestsdef search(term, media):    url = "https://itunes.apple.com/search"    payload = {"term": term, "media": media}    response = requests.get(url, params=payload)    response.raise_for_status()    results = response.json().get("results", [])    return results

>>> results = search("python", media="podcast")>>> results[0]["collectionName"]'Talk Python To Me'

Параметры запроса


Поиск можно настроить:


  • term поисковый запрос, единственный обязательный параметр;
  • media тип произведения (movie, podcast, music, audiobook, software, ebook, all), поумолчанию all;
  • country страна произведения, двухсимвольный ISO-код (us, ru, ...), по умолчанию us;
  • limit максимальное количество результатов, по умолчанию 50.

Пример функции, которая поддерживает все параметры:


import requestsdef search(term, media="all", country="us", limit=10):    url = "https://itunes.apple.com/search"    payload = {"term": term, "media": media, "country": country, "limit": limit}    response = requests.get(url, params=payload)    response.raise_for_status()    results = response.json().get("results", [])    return results

Ответ


Общая структура ответа:


{    "resultCount": 10,    "results": [        {            "wrapperType": "track",            "kind": "song",            "artistId": 1495668306,            "collectionId": 527039271,            "trackId": 527039276,            "artistName": "Dodge & Fuski",            "collectionName": "Never Say Die (Deluxe Edition)",            "trackName":"Python",            ...        },         {            "wrapperType": "track",            "kind": "podcast",            "collectionId": 979020229,            "trackId": 979020229,            "artistName": "Michael Kennedy (@mkennedy)",            "collectionName": "Talk Python To Me"            ...        },        ...    ]}

Конкретный набор полей зависит оттипа произведения (kind) иполноценно нигде неописан, насколько мне известно. Часто заполнены:


  • artistId идентификатор автора произведения;
  • artistName автор;
  • artistViewUrl ссылка на автора на сайте Apple;
  • collectionId идентификатор альбома;
  • collectionName название альбома;
  • collectionViewUrl ссылка на альбом на сайте Apple;
  • trackId идентификатор композиции;
  • trackName название композиции;
  • artworkUrl100 ссылка на превьюшку произведения 100x100 пикселей;
  • country страна произведения;
  • primaryGenreName жанр произведения.

Для подкастов ясделал типизированную обёртку пакет podsearch, можно посмотреть набор полей внём.


Запрос поидентификатору


Если известен идентификатор объекта (artistId, collectionId, trackId), можно вызвать метод lookup понему:


import requestsdef lookup(object_id):    url = "https://itunes.apple.com/lookup"    payload = {"id": object_id}    response = requests.get(url, params=payload)    response.raise_for_status()    results = response.json().get("results", [])    return results

>>> results = lookup(979020229)>>> results[0]["collectionName"]'Talk Python To Me'

Нюансы


Про необычный Content-Type ответа я уже упомянул. Кроме того:


  • Страна произведения (country) есть как впараметрах запроса, так и вответе. Но впараметрах это двухсимвольный ISO-код (ru), а вответетрёхсимвольный (RUS).
  • Схемы ответа несуществует.
  • Apple ограничивает частоту вызова API 20 запросами вминуту.

Описание API на сайте Apple
Пакет для поиска по подкастам


Если хотите больше интересных штук наPython подписывайтесь на канал @ohmypy

Подробнее..

В чём сила дашбордов, как тестировать JS-библиотеки и чего стоит выпустить собственный фреймворк в open source

04.07.2020 12:05:52 | Автор: admin
Пост посвящается всем, кто виртуально не добрался до нашего онлайн-митапа, который мы посвятили инструментам автоматического тестирования. Без лишних слов публикуем видео с BugsBusters 2020 смотрите прямо сейчас, будет хорошее начало выходных.



Сила дашбордов

Егор Иванов, специалист по автоматизации тестирования (Яндекс.Деньги)

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


Таймкоды
0:55 Каким специалистам будет полезен доклад
1:10 Что такое дашборд? Примеры из жизни. Определение термина, основные типы.
4:05 Знакомство с командой интеграционного тестирования. Схема взаимодействия инструментов: Jira, Autorun, Locker, Pinger, Jenkins
7:32 Что делать, когда что-то идет не так роль дежурного
8:15 Дашборд дежурного: мастштабирование задач, использование Grafana
11:26 Как происходит отсылка метрик. Типы метрик.
13:09 Процесс отправки метрик из Java и sh
14:10 Как построить дашборд? Как можно использовать дашборды?
15:00 Пример 1 дашборд как визуализатор метрик
18:20 Пример 2 дашборд как мотиватор
22:18 Пример 3 дашборд для анализа
24:45 Пример 4 дашборд для экономии времени
27:00 Подведение итогов: что мы получили от внедрения дашбордов



Святой Грааль автоматизации: не можешь найти создай сам

Андрей Ганин, QA Head (Альфа-Банк)

Кажется, выбор инструментов для автоматизации огромный ровно до тех пор, пока вам не понадобятся E2E-тесты на C#. Я расскажу о том, как мы создавали собственный фреймворк: о трудностях, несбывшихся надеждах и тонкостях выпуска внутреннего продукта в open source.


Таймкоды
1:30 О чем пойдет речь в докладе?
2:20 Предыстория: как Альфа-банк задумался о сокращении времени на проверку внутренних продуктов.
3:32 Выявление основной проблемы отсутствии документации.
4:21 Итоги первой реализации фреймворка
5:28 Описание второй итерации. SpecFlow. Итоги второй реализации
8:32 What if?.. Создание инструмента, который мог бы безошибочно и без установки дополнительного ПО создавать автотесты.
9:20 Схема взаимодействия внутренний инструментов AFT Desk
10:58 А зачем это всё?
13:35 Разделение тестов с фреймворком. Как это происходит внутри?
16:31 Глобальное изменение: прекращение Microsoft развития фреймворка Net Framework. Переход на Net Standard
18:20 Как изменился процесс после перехода. Плюсы и минусы
20:57 Применимость фреймворка. Примеры. Паттерны Page Object
23:11 Как использовать технологии?
24:17 Как выглядит релиз новой версии в Open Source. Различия с внутренним решением
26:44 Выводы: зачем использовать фреймворк и кому это может пригодится? Планы развития



Как мы тестируем виджет Яндекс.Кассы

Дмитрий Сергиенко, старший тестировщик (Яндекс.Деньги)
Виджет Яндекс.Кассы это JS-библиотека, которая работает через iframe. Расскажу о своём опыте тестирования и о нашем инструменте WidgetRunner.


Таймкоды:
0:32 Как тестировать JS-библиотеку?
0:54 Виджет Яндекс.Кассы: что это такое.
2:45 Почему мы решили использовать iframe
3:04 Как же это все тестировать? Первый вариант (статичный html-файл), его минусы.
3:45 О платежном токене: что это и как его получить.
5:01 Почему 1 подход не сработал? Следующие подходы
6:09 Почему плохо тестировать только форму оплаты?
7:48 Требования к инструменту тестирования
8:40 WidgetRunner как работает инструмент и его функциональность
11:52 Выводы: что получили с внедрением инструмента WidgetRunner



Наш первый митап в онлайне прошел круто и драйвово: чуть больше 200 слушаталей в прямом эфире! А под конец мы еще и подарочные сертификаты разыграли в викторине участники остались довольными.

P.S. Скоро откроем регистрацию на Android-митап, на котором затронем темы мобильного тестирования. Следите за новостями!
Подробнее..

Godot, 1000 мелочей

01.07.2020 20:13:32 | Автор: admin
Недавно открыл для себя Godot engine, опенсурсный игровой движок. Делюсь некоторыми приёмами и заметками, в основном из области 3д, кода или общих моментов.


У Godot в целом репутация скорее 2д движка, которое проработано довольно хорошо, но и не так давно появившиеся 3д возможности позволяют делать трёхмерные игры. Особенно если вы в состоянии оптимизировать какие-то вещи самостоятельно, не делаете слишком уж тяжёлую и комплексную игру, а также вас устраивают текущие варианты рендера. Ну или можете ждать будущих оптимизаций и появления vulkan.

Из коробки в движке есть некоторая физика, в том числе джоинты и колёсный транспорт. Нет встроенного редактора terrain, но можно воспользоваться плагином, импортировать из специализированных программ или просто как меш из 3д пакета. В последнем случае ради производительности придётся самостоятельно резать ландшафт на фрагменты-чанки, и скорее всего делать им отдельные меши под коллизии. Что касается мешей под форму коллизии ландшафта чтобы не было визуальных нестыковок, нужно триангулировать модель во время экспорта из 3д пакета. Например, один из простейших способов это сделать в Blender экспортировать меш в формате collada (.dae), там по дефолту стоит галочка triangulate.

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


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

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

Сигналы


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


Заводим сигнал

Излучаем его в том же скрипте при нажатии кнопки или других условиях

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


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

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


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

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



CGS-объекты



Один из полезных 3д инструментов в Godot примитивы constructive solid geometry. Проще говоря это объекты, поддерживающие булевы операции пересечение, исключение, объединение. Кроме набора примитивов есть универсальный CGS Mesh, в качестве формы для которого можно установить уже произвольный меш.



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

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

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




Далее у нас идут CGS движущиеся. Через код, либо записанную анимацию. В целом через этот способ можно реализовывать какие-то эффекты, но очень желательно чтобы подобные анимации не крутились на сцене в цикле. Несколько анимированных CGS могут заметно посадить производительность, к тому же в Godot оптимизирует не все вещи, и если вы не вырубите анимированные CGS самостоятельно, то они будут продолжать расходовать производительность вне видимости камеры.
Тем не менее эффекты анимированных CGS уже сложно заменить решениями 3д пакета, поэтому вы можете быть заинтересованы именно в их использовании (по крайней мере, если не собираетесь рисовать продвинутое 3д через код). Главное найти им правильное применение, лучше всего их использовать точечно, в определённых местах, включая анимацию по триггеру. Как эффект открытия прохода или прочий разовый спецэффект. Естественно, чем проще форма CGS объектов тем лучше. А основную вычислительную нагрузку они оказывают именно в процессе соприкосновения в движении, притом нет особой разницы, какой именно объект двигать относительно другого.


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

Сущности для платформы Яндекс.Диалоги

04.07.2020 16:09:21 | Автор: admin
В прошлую субботу состоялся онлайн-хакатон по разработке навыков Алисы. Жаль, что никто не написал здесь об итогах, любопытно почитать истории победителей. Но раз желающих не нашлось, то поделюсь своей историей.

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



Пользовательские сущности в Диалогах


Когда я говорю умной колонке купи одну акцию Яндекс, то речь проходит через внутреннюю магию платформы Яндекс.Диалоги, затем попадает в веб-хук, который я указал в качестве обработчика навыка. Вот что приходит в обработчик:
  "request": {    "command": "купи одну акцию яндекс",    "original_utterance": "купи одну акцию яндекс",    "nlu": {      "tokens": [        "купи",        "1",        "акцию",        "яндекс"      ],      ...      "intents": {        "market.order": {          "slots": {            "amount": {              "type": "YANDEX.NUMBER",              "tokens": {                "start": 1,                "end": 2              },              "value": 1            },            "unit": {              "type": "OperationUnit",              "tokens": {                "start": 2,                "end": 3              },              "value": "share"            },            "figi": {              "type": "EFigi",              "tokens": {                "start": 3,                "end": 4              },              "value": "BBG006L8G4H1"            },            "operation": {              "type": "OperationType",              "tokens": {                "start": 0,                "end": 1              },              "value": "buy"            }          }        }      }    },    ...  },

Обратите внимание на слот figi, в котором содержится идентификатор акции Яндекс, так называемый FIGI (Financial Instrument Global Identifier), необходимый для взаимодействия с API торговой платформы Тинькофф Инвестиции. Тип данных EFigi, это пользовательская сущность, которую я описал в разделе Сущности при создании навыка в платформе Яндекс.Диалоги. Вот фрагмент описания:
entity EFigi:    values:        BBG005DXJS36:            %exact            TCS            %lemma            тиньков(банк)?            тинькоф(банк)?            тинькофф(банк)?            ти си эс (груп)?        BBG006L8G4H1:            %exact            YNDX            %lemma            яндекс            яндекса        BBG004730JJ5:            %exact            MOEX            %lemma            Московская Биржа            Мосбиржа        BBG002B2J5X0:            %exact            KRKNP            %lemma            [Саратовский НПЗ акции привилегированные]            [Саратовский нефтеперерабатывающий завод акции привилегированные]...

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

Я использую EFigi в качестве нетерминала грамматики и типа слота в интентах. Интенты это такие регулярные выражения на стероидах в Диалогах. Благодаря интентам Диалоги понимают, какие данные нужно извлечь из пользовательского запроса и передать в обработчик. Вот пример интента для команды покупки/продажи ценных бумаг на бирже по рыночной цене:
slots:    operation:        source: $Operation        type: OperationType    figi:        source: $Stock        type: Efigi    amount:        source: $Amount        type: YANDEX.NUMBER    unit:        source: $Unit        type: OperationUnitroot:    $Operation [$Amount $Unit $Stock]$Operation:    $OperationType$Amount:    $YANDEX.NUMBER$Unit:    $OperationUnit$Stock:    $EFigi

Это похоже на регулярные выражения.

Библиотека сущностей для Диалогов


Во время хакатона по разработке навыков для Алисы я создал репозиторий alice-entities-library, запушил туда сущность EFigi и отправился на GitHub искать репозитории, в которых есть описание пользовательских сущностей. Ожидал, что найду сотни репозиториев, свяжусь с разработчиками и предложу прислать пул-реквесты в библиотеку сущностей.

Репозитории искал по тегам: yandex-dialogs, alice-skills, yandex-alice и alice-sdk. Оказалось, мало кто использует теги на GitHub, мне удалось найти всего один репозиторий, содержащий файл с описанием сущности ELang. По стечению обстоятельств автором репозитория оказался Давид один из организаторов хакатона. Я предложил Давиду добавить сущность ELang в библиотеку и через несколько минут получил от него пул-реквест.

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

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


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

Пожалуйста, добавляйте теги yandex-dialogs, alice-skills и yandex-alice к репозиториям, чтобы другие могли находить ваши навыки на GitHub.

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

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

Open Source родина нашего страха

05.07.2020 20:11:11 | Автор: admin
Наверное никому на этом сайте не нужно объяснять что такое опенсорс. Обычно этот вид ПО упоминается исключительно в положительном контексте. И да, действительно, феномен свободного и открытого ПО изменил мир. Мы каждый день пользуемся его плодами, будь то Git, библиотеки или же что-то более приземленное, вроде какого-нибудь графического редактора. При всех достоинствах этого явления, у него есть и обратная сторона.

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


Никаких гарантий


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

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

Ожирение


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

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

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

Бесплатный труд


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

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

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

Конкуренция мертва


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

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

Весёлые собеседования


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

Итого


В мире где человек человеку волк, в отрасли, где делаются огромные бабки складывается шизофреническая ситуация. С одной стороны система превращает все больше и больше аспектов нашей жизни в товар и хочет поиметь с нас немножечко гешефта, с другой мы слышим как классно менять мир и решать ИНТЕРЕСНЕ ЗАДАЧКИ, бесплатно делиться знаниями и результатами своего труда. Не знаю как так получилось, но мы с радостью ведемся на этот булщит и бежим покопаться в КИШОЧКАХ ДЖЭВЭЭМ за минимальный прайс, а то и вообще бесплатно. Откуда в нас такая инфантильность? Но похоже, что пошатнувшаяся в этот кризис уверенность айти-бояр в собственной исключительности и безопасности заставит нас пересмотреть наши взгляды.
Подробнее..
Категории: Open source , Труд

Перевод Разработка безопасных алгоритмов Проектирование

06.07.2020 18:16:50 | Автор: admin
Представьте себе водопад. Мощный. Безупречный. Всегда движется вперед по направлению к неминуемому спуску. Движимый одной из нескольких фундаментальных сил во вселенной.

Водопады потрясают по самой своей сути, так что неудивительно, что инженеры немного одержимы ими. Старый стандарт DOD-STD-2167A рекомендовал использовать водопадную модель, а мое устаревшее инженерное образование основывалось на модели Phase-Gate, которая, по моему мнению, чертовски похожа на водопадную. С другой стороны, те из нас, кто изучал информатику в университете, наверное, знают, что водопадная модель в некоторой мере является анти-паттерном. Наши друзья в академической башне из слоновой кости говорят нам, что нет-нет, Agile это путь, к успеху и похоже, индустрия доказала истинность этого утверждения.

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

Как обычно в жизни, ответ находится где-то посередине.

Гибридная, спиральная и V-образная модели


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

Звучит неплохо, но насколько это действительно эффективно?

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

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

Практическое применение

Говоря более конкретно, мы с рабочей группой NDT в Autoware.Auto, закончили наш первый спуск по левому каскаду V-образной модели (то есть совершили первую итерацию через этап проектирования) в рамках подготовки к Autoware Hackathon в Лондоне (его проводит Parkopedia!). Наш первый проход через этап проектирования состоял из следующих этапов:

  1. Обзор литературы
  2. Обзор существующих реализаций
  3. Проектирование компонентов высокого уровня, вариантов использования и требований
  4. Анализ неисправностей
  5. Определение метрик
  6. Архитектура и дизайн API


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

Обзор литературы и существующих реализаций


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

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

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

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

Из нашего обзора литературы по NDT, мы собрали следующие полезные фрагменты информации:

  • Семейство алгоритмов NDT имеет несколько вариаций:
    P2D
    D2D
    Ограниченный
    Семантический
  • Существует куча грязных трюков, которые можно использовать, чтобы заставить алгоритм работать лучше.
  • NDT обычно сравнивается с ICP
  • NDT немного быстрее и немного надежнее.
  • NDT надежно работает (имеет высокий коэффициент успешности) в пределах определенной местности


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

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

Варианты использования, требования и механизмы


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

  1. Какие варианты использования вы пытаетесь решить?
  2. Каковы требования (или ограничения) к решению для удовлетворения вышеуказанных случаев использования?
  3. Какие механизмы удовлетворяют вышеуказанным требованиям?


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

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

Варианты использования


Мне нравятся три мысленных подхода к вариантам использования (внимание, я не специалист по функциональной безопасности):

  1. Что вообще должен делать компонент? (помните о SOTIF!)
  2. Каковы способы, которыми я могу ввести входные данные в компонент? (входные варианты использования, мне нравится называть их восходящими)
  3. Каковы способы, которыми я могу получать выходные данные? (выходные или нисходящие варианты использования)
  4. Бонусный вопрос: В каких цельных архитектурах систем может находиться этот компонент?


Собрав всё вместе, мы придумали следующее:

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


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

Требования


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

В конце концов, общие требования к системе локализации не так уж и страшны:

  • Обеспечить преобразования для локальных алгоритмов
  • Обеспечить преобразования для глобальных алгоритмов
  • Обеспечить работу механизма для инициализации алгоритмов относительной локализации
  • Убедиться, что преобразования не разрастаются
  • Обеспечить соответствие REP105


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

Механизмы


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

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

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

image

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

Анализ неисправностей


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

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

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

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

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

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

Всего мы выработали 15 рекомендаций. Я бы рекомендовал вам ознакомиться с ними.

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

Определение метрик


То, что измеряется поддается управлению
Популярная фраза менеджеров


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

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

Для нашей реализации NDT мы разбили метрики на четыре широкие группы:

  1. Общие метрики качества программного обеспечения
  2. Общие метрики качества встроенного программного обеспечения
  3. Общие метрики алгоритма
  4. Специфические для локализации метрики


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

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

Архитектура и API


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

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

Как это выглядит?

Вместо внесения монолитного тикета под названием Реализовать NDT (включая тесты), в результате которого будет написано несколько тысяч строк кода (которые невозможно эффективно просмотреть и изучить), можно разбить проблему на более содержательные фрагменты:

  1. Написать классы и публичные методы для алгоритма (создать архитектуру)
  2. Написать тесты для алгоритма с использованием публичного API (они должны проваливаться!).
  3. Реализовать логику алгоритма


Итак, первый шаг написать архитектуру и API для алгоритма. О других шагах я расскажу в другой заметке.

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

Каковы же тогда степени свободы в NDT?

Обзор литературы говорит нам о том, что существуют различные способы представления сканирования и наблюдения (например, P2D-NDT и D2D-NDT). Аналогичным образом, наш инженерный документ высокого уровня говорит о том, что у нас имеется несколько способов представления карты (статический и динамический), так что это тоже степень свободы. В более свежей литературе также говорится о том, что задача оптимизации может быть пересмотрена. Тем не менее, сравнивая практическую реализацию и литературу, мы видим, что даже детали решения для оптимизации могут отличаться.

И список можно продолжать и продолжать.

По итогам первичного проектировании мы остановились на следующих концепциях:

  • Проблемы оптимизации
  • Решения для оптимизации
  • Представление сканирования
  • Представление карты
  • Первоначальные системы генерации гипотез
  • Алгоритм и узловые интерфейсы


С некоторым подразделением внутри этих пунктов.

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

Далее


После проектирования, конечно, приходит время реализации. Официальная работа по внедрению NDT в Autoware.Auto была проведена на хакатоне Autoware, организованном Parkopedia.

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

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

Подписывайтесь на каналы:
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu новости автоиндустрии, железо и психология вождения




image

О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

Читать еще полезные статьи:

Подробнее..

Перевод Гайд по DevOps для начинающих

06.07.2020 18:16:50 | Автор: admin
В чем важность DevOps, что он означает для ИТ-специалистов, описание методов, фреймворков и инструментов.

image

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

Что такое DevOps


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

Слово DevOps является объединением слов разработка (development) и операции (operations). DevOps помогает увеличить скорость доставки приложений и услуг. Это позволяет организациям эффективно обслуживать своих клиентов и становиться более конкурентоспособными на рынке. Проще говоря, DevOps это согласованность между разработкой и ИТ-операциями с более эффективным взаимодействием и сотрудничеством.

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

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

Вызовы для команды разработчиков


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

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


Проблемы, с которыми сталкивается операционная группа


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

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


Как DevOps решает проблемы разработки и операций


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

  • Снизить процент отказов при выпуске новых релизов
  • Увеличить частоту развертывания
  • Достичь более быстрого среднего времени на восстановление в случае выхода нового релиза приложения.
  • Сократить время на исправления


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

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

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


image

Противостояние DevOps, Agile и традиционного IT


DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.

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

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

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


Жизненный цикл DevOps


DevOps подразумевает принятие определенных общепринятых практик.

Непрерывное планирование


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

Совместное развитие


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

Непрерывное тестирование


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

Непрерывные выпуск и развертывание


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

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

Непрерывный мониторинг


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

Постоянная обратная связь и оптимизация


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

image

Преимущества DevOps


DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.

Важными преимуществами DevOps являются:

  • Предсказуемость: DevOps предлагает значительно более низкую частоту отказов при выпуске новых релизов.
  • Поддерживаемость: DevOps обеспечивает легкое восстановление в случае сбоев в новом релизе или отключения приложения.
  • Воспроизводимость: Система контроля версий сборки или кода позволяет восстанавливать более ранние версии по мере необходимости.
  • Более высокое качество: Решение проблем с инфраструктурой улучшает качество разработки приложений.
  • Время выхода на рынок: Оптимизация доставки программного обеспечения сокращает время выхода на рынок на 50%.
  • Снижение риска: Обеспечение безопасности в жизненном цикле программного обеспечения снижает количество дефектов на протяжении всего жизненного цикла.
  • Экономическая эффективность: Стремление к экономической эффективности при разработке программного обеспечения нравится высшему руководству.
  • Устойчивость: Программная система более стабильна, безопасна, а изменения можно проверять.
  • Более крупная кодовая база разбивается на управляемые части: DevOps основан на гибких методах разработки, которые позволяют разбивать большую кодовую базу на более мелкие и управляемые части.


Принципы DevOps


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

Разрабатывайте и тестируйте в среде, похожей на производственную


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

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

Развертывание с воспроизводимыми, надежными процессами


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

Мониторинг и проверка качества работы


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

Усовершенствование циклов обратной связи


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

Dev


  • Планирование: Kanboard, Wekan и другие альтернативы Trello; GitLab, Tuleap, Redmine и другие альтернативы JIRA; Mattermost, Roit.im, IRC и другие альтернативы Slack.
  • Написание кода: Git, Gerrit, Bugzilla; Jenkins и другие инструменты с открытым исходным кодом для CI/CD
  • Сборка: Apache Maven, Gradle, Apache Ant, Packer
  • Тесты: JUnit, Cucumber, Selenium, Apache JMeter


Ops


  • Выпуск, развертывание, операции: Kubernetes, Nomad, Jenkins, Zuul, Spinnaker, Ansible, Apache ZooKeeper, etcd, Netflix Archaius, Terraform
  • Мониторинг: Grafana, Prometheus, Nagios, InfluxDB, Fluentd, и другие, покрытые в этом руководстве


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

В заключение


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

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:




Полезное


Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru