Opensourse

Приветствую читателей!

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

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

Способ 1

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

Для удобства набор символов, таблица, желательно чтобы была равносторонней, то есть или 10х10, или 25х25, или 100х100, или иной вариант который вы пожелаете, но не обязательно, и желательно чтобы в итоге ваш пароль в итоге был не менее 20 символов. Чем больше различных букв, цифр, символов в таблице, тем безопаснее. Хорошо не забывать и про использование как строчных, так и заглавных букв в своём наборе, что усложнит попытки подбора пароля злоумышленникам. Таблицы можно легко удобно создавать в LibreOffice Calc или если вы сидите на мелко-мягкой проприетарщине, то MS Excel.

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

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

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

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

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

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

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

Способ 2

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

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

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

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

А для расчёта хеш-сумм можно использовать разные утилиты. Для GNU/Linux систем можете установить GTKHash.

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

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

Заключение

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

Приветствую читателей.

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

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

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

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

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

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

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

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

Третий вариант. Virt-manager также, как и предыдущие менеджеры работает с QEMU и KVM через libvirt, но кроме того может работать и с иными вариантами виртуализации, не только с гипервизорами, но и с более лёгким вариантом виртуализации, а именно, с контейнерной виртуализацией,

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

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

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

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

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

На этом завершаем теорию и в следующей публикации разберём работу с QEMU и KVM. Существует и ещё один добротный вариант, это Xen, с которым также работает virt-manager, и я уважаю этот гипервизор и регулярно использую его. О нём я рассказывал в отдельном выпуске о виртуализации. А связка QEMU и KVM является доступной, лёгкой в работе, пожалуй, чуть более удобнее для простых пользователей и не требуется при загрузке операционной системы в загрузочном GRUB-меню выбирать никакие варианты.

В последующих публикациях я покажу работу virt-manager с QEMU-KVM, которая будет понятна даже не продвинутому пользователю, что считаю особо общественно-полезным делом, тем более, что работе данного ПО даже в английском сегменте интернета не достаточно информации на мой взгляд. А в русско-язычной сфере, так я вообще не встречал ничего особо достойного по данной теме. Лишь малоценные поверхностные обзоры.

Всем развития и успехов.

Меня зовут Ксюша Луговая. В СберКорусе я занимаюсь поддержкой библиотеки React-компонентов Korus-UI.

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

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

Основные критерии выбора библиотеки

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

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

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

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

• Хорошо ли составлена документация проекта, есть ли интерактивные примеры?

• Насколько активно поддерживается проект?

• Сколько в проекте issues и как быстро они решаются?

• Проект бесплатный или коммерчески лицензированный?

• Насколько легко настраиваются компоненты?

• Покрыт ли код библиотеки тестами?

• Какие браузеры и платформы поддерживает библиотека?

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

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

• Material-UI,

• Semantic-UI-React,

• yandex-ui,

• arui-feather,

• Korus-UI.

С одной стороны, в этом списке представлены наиболее популярные проекты Material-UI и Semantic-UI-React, которые были созданы одним разработчиком и со временем обросли большим сообществом.

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

Далее рассмотрим сравнение библиотек в разрезе определенных выше критериев.

Компонентный состав

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

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

Layout-компоненты

Контейнеры, карточки, таблицы, гриды и прочие. Основные характеристики:

• Отвечают только за отображение;

• Часто принимают на вход только props.children;

• Не имеют своего состояния и методов жизненного цикла;

• Примеры: h1, section, div, span, Icon, Avatar.

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

Компоненты-контролы (controls)

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

Основные характеристики:

• Отвечают за отображение и не имеют внутреннего состояния;

• Принимают данные и функции обратного вызова в качестве props;

• Состояние компонентов связано в основном только с UI (disabled, required, isLoading).

Сложные модульные компоненты

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

Основные характеристики:

• Имеют состояние;

• Предоставляют данные и логику layout-компонентам (валидация, форматирование вывода, автодополнение);

• Комбинируют другие компоненты.

*Material-UI использует нативный календарь браузера в компонентах с выбором даты

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

***Korus-UI создает обертку для всех основных HTML-тегов c единым API

Почти 50% компонентного состава Material-UI и Semantic-UI-React и около 30% вбиблиотеках yandex-ui и arui-feather малофункциональные layout-компоненты. ВKorus-UI более 70% сложные модульные компоненты.

Кастомизируемость

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

Material-UI

• С помощью MuiThemeProvider. Компонент использует контекст библиотеки React для передачи объекта с темой всем дочерним компонентам.

• Через добавление классов. Все компоненты поддерживают атрибут className.

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

Библиотека заточена на применение CSS-in-Js, что может вызвать определенные трудности, если стили для приложения содержатся в CSS-файлах. Для внедрения кастомных стилей CSS-in-Js предоставляется HOC withStyles() либо хук makeStyles() для функциональных компонентов.

Semantic-UI-React

У Semantic-UI-React нет своей темы, можно использовать стили Semantic-UI.

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

Это:

• Изменение размеров контейнера страницы, шрифтов и цветов по умолчанию с помощью site.variables;

• Переопределение css-переменных ;

• Объединение нескольких отдельных тем компонентов в один файл theme.config;

• Изменение пути к assets и использование кастомного иконочного шрифта.

yandex-ui

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

Возможности:

• Создание кастомной темы с помощью инструмента themekit;

• Переопределение значения (токены) в теме;

• Дизайн-токены в формате yaml или json. Их можно собрать в итоговый файл (css, json, js, ios, android) и подключить к проекту.

arui-feather (Альфа Банк)

У библиотеки Альфа Банка нет руководства по кастомизации стилей в общедоступной документации. Компоненты поддерживают атрибут className, возможно задать кастомные классы только их оберткам.

Korus-UI (СберКорус)

• Кастомизация темы с помощью компонента LedaProvider. Он использует контекст библиотеки React для передачи объекта с темой всем дочерним компонентам.

• Можно написать кастомные стили под имеющуюся вёрстку. Полный список классов вкомпонентах находится в разделе API-документации (см.атрибут theme). Их можно переопределять глобально для всех компонентов одного типа или для каждого индивидуально.

Расширяемость

В работе с библиотекой может возникнуть потребность изменить внутренний элемент компонента. Например, добавить картинку или иконку в поле ввода, заменить элемент нановый (в компонент Loader передать кастомный элемент спиннера).

Рассмотрим решения.

Material-UI

Позволяет изменять корневые элементы с помощью атрибута component.

Например, компонент List по дефолту рендерит <ul> элемент. Его можно заменить другим элементом или React компонентом:

<List component="nav">  <ListItem button><ListItemText primary="Trash" /></ListItem><ListItem button><ListItemText primary="Spam" /></ListItem></List>

Semantic-UI

Semantic-UI-React компоненты поддерживают схожий по функциональности атрибут as:

<Button as='a' />

Переданный элемент или React-компонент заменяют корневой элемент. Все неподдерживаемые пропсы передаются корневому элементу в качестве атрибутов.

yandex-ui

Предлагает использовать библиотеку render-override. В ней есть набор хуков икомпонентов для реализации переопределения элементов внутри составного компонента.

Пример:

import React from 'react'import { useRenderOverride } from '@yandex/ui/lib/render-override'const ElementOriginal = ({ children }) => <div>{children}</div>const MyComponent = ({ renderElement }) => {  const Element = useRenderOverride(ElementOriginal, renderElement) return ( <>   <Element />   </>  )}

В библиотеке yandex-ui расширяемость для существующих компонентов нереализована.

arui-feather (Альфа Банк)

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

Korus-UI

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

Простейший пример:

labelRender={() => <MyCustomLabel />}

Структура метода позволяет вносить изменения максимально гибко:

({ Element, elementProps, componentProps, componentState }) => React.Node

• Element - сам элемент

• elementProps - props элемента

• componentState, componentProps - для удобства дополнительно приходят объекты с props и state всего компонента

Если мы хотим, чтобы новый элемент принимал на вход те же пропсы, можно отредактировать пример:

<L.CheckBox  labelRender={({ elementProps }) => <MyCustomLabel {elementProps} />}>  Label</L.CheckBox>

Типизация

Для типизации React-проектов применяются 2 основных инструмента:

• Typescript

• PropTypes

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

В основном рассматриваемые библиотеки для типизации используют Typescript. УSemantic-UI основная библиотека написана на ванильном JS, а Typescript используется только в Semantic-UI-React, созданной для интеграции с библиотекой React.

Покрытие тестами

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

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

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

Сравним библиотеки на покрытие тестами.

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

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

Поддержка

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

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

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

В разделе Pulse на GitHub можно ознакомиться со статистикой репозитория по количеству Pull Request и коммитов за определенный период времени. Он находится навкладке Insights каждого репозитория. Рассмотрим статистику по выбранным библиотекам.

Material-UI

Semantic-UI

yandex-ui

arui-feather (Альфа Банк)

Korus-UI (СберКорус)

Популярность

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

Однако стоит помнить, что популярность это также результат хорошей маркетинговой стратегии и SEO-оптимизации, которые могут обеспечить библиотеке первые места в выдаче поисковика. Поэтому следует изучить обсуждения в блогах инафорумах, например, на Stackoverflow, Medium, DEV. Обсуждения находятся вразделе issues проекта.

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

Работа с формами и валидация данных

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

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

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

Сравним работу с формами в различных библиотеках на конкретном примере.

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

Korus-UI

const BasicForm = () => (  <L.Div>    <L.Input      isRequired      requiredMessage="Login is required"      form="form"      name="login"      placeholder="Login"    />    <L.Input      isRequired      requiredMessage="Password is required"      form="form"      name="password"      placeholder="Password"    />    <L.Button _warning form="form">      Submit    </L.Button>  </L.Div>);

Material-UI

const BasicForm = () => {  const [login, setLogin] = React.useState("");  const [loginError, setLoginError] = React.useState(false);  const [password, setPassword] = React.useState("");  const [passwordError, setPasswordError] = React.useState(false);  return (    <div>      <form        onSubmit={(e) => {          e.preventDefault();          setLoginError(!login);          setPasswordError(!password);        }}      >        <p>          <TextField            error={loginError}            placeholder="Login"            value={login}            onChange={(e) => {              setLoginError(false);              setLogin(e.target.value);            }}            onBlur={(e) => {              setLoginError(!login);            }}            helperText={loginError && "Login is required"}          />        </p>        <p>          <TextField            error={passwordError}            placeholder="Password"            value={password}            onChange={(e) => {              setPasswordError(false);              setPassword(e.target.value);            }}            onBlur={(e) => {              setPasswordError(!password);            }}            helperText={passwordError && "Password is required"}          />        </p>        <Button type="submit" color="primary" variant="contained">          Sign Up        </Button>      </form>    </div>  );};

Semantic-UI-React

const BasicForm = () => {  const [login, setLogin] = React.useState("");  const [loginError, setLoginError] = React.useState(false);  const [password, setPassword] = React.useState("");  const [passwordError, setPasswordError] = React.useState(false);  return (    <div>      <Form        onSubmit={(e) => {          e.preventDefault();          setLoginError(!login);          setPasswordError(!password);        }}      >        <Form.Group>          <Form.Input            error={loginError && { content: "Login is required" }}            placeholder="Login"            name="login"            value={login}            onChange={(e) => {              setLoginError(false);              setLogin(e.target.value);            }}            onBlur={(e) => {              setLoginError(!login);            }}          />          <Form.Input            error={passwordError && { content: "Password is required" }}            placeholder="password"            name="password"            value={password}            onChange={(e) => {              setPasswordError(false);              setPassword(e.target.value);            }}            onBlur={(e) => {              setPasswordError(!password);            }}          />          <Form.Button content="Submit" />        </Form.Group>      </Form>    </div>  );};

arui-feather

const BasicForm = () => {  const [login, setLogin] = React.useState("");  const [loginError, setLoginError] = React.useState(false);  const [password, setPassword] = React.useState("");  const [passwordError, setPasswordError] = React.useState(false);  return (    <Form      onSubmit={(e) => {        e.preventDefault();        setLoginError(!login);        setPasswordError(!password);      }}    >      <FormField>        <Input          error={loginError && "Login is required"}          placeholder="Login"          value={login}          onChange={(value) => {            setLoginError(false);            setLogin(value);          }}          onBlur={(e) => {            setLoginError(!login);          }}        />      </FormField>      <FormField>        <Input          error={passwordError && "Password is required"}          placeholder="Password"          value={password}          onChange={(value) => {            setPasswordError(false);            setPassword(value);          }}          onBlur={(e) => {            setPasswordError(!password);          }}        />      </FormField>      <FormField>        <Button view="extra" type="submit">          Submit        </Button>      </FormField>    </Form>  );};

yandex-ui

const BasicForm = () => {  const [login, setLogin] = React.useState("");  const [loginError, setLoginError] = React.useState(false);  const [password, setPassword] = React.useState("");  const [passwordError, setPasswordError] = React.useState(false);  return (    <form      onSubmit={(e) => {        e.preventDefault();        setLoginError(!login);        setPasswordError(!password);      }}      className={cnTheme(theme)}    >      <Textinput        error={loginError}        placeholder="Login"        value={login}        onChange={(e) => {          setLoginError(false);          setLogin(e.target.value);        }}        onBlur={(e) => {          setLoginError(!login);        }}        hint={loginError && "Login is required"}      />      <Textinput        error={loginError}        placeholder="Password"        value={password}        onChange={(e) => {          setPasswordError(false);          setPassword(e.target.value);        }}        onBlur={(e) => {          setPasswordError(!login);        }}        hint={passwordError && "Password is required"}      />      <Button type="submit" view="action">        Submit      </Button>    </form>  );};

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

В Material-UI и yandex-ui нет компонента формы, в Semantic-UI-React и arui-feather компонент формы является простой оберткой тега <form> и не предоставляет никакой дополнительной функциональности.

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

Сравнительный анализ библиотек React-компонентов

Подведем итог сравнительного анализа пяти библиотек React-компонентов.

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

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

Почему Korus-UI

Может возникнуть вопрос: зачем нужна еще одна библиотека? На рынке уже существует большое количество библиотек компонентов React на любой вкус.

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

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

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

На разработку библиотеки Korus-UI ушло 1,5 года. В процессе создания мы ориентировались на лучшие практики разработки opensource-библиотек.

Какие преимущества предоставляет Korus-UI

Формы и валидация

В Korus-UI подход к построению форм принципиально иной: поля и кнопка отправки формы связываются атрибутом form, в который передается строка с названием формы. Так элементы одной формы могут находиться в разных контейнерах, подключаться динамически, никакие общие обертки им не нужны. При этом создается объект формы, ккоторому можно получить доступ в обработчиках событий или с помощью метода L.form(). Есть возможность передать кнопке массив из названий форм, чтобы валидировать и отправлять несколько форм одним кликом.

У библиотеки Korus-UI удобный обработчик onValidationFail, который позволяет получить объект формы, не прошедшей валидацию. А еще есть приятный бонус прокрутки к невалидным полям.

Валидация в Korus-UI это отдельный компонент. Его основные фичи:

• Валидация поля функцией или RegExp

• Готовые валидаторы

• Один или несколько валидаторов для каждого поля со своими сообщениями

• Настраиваемые сообщения (текст и внешний вид)

• Задание валидности поля извне через атрибут isValid

• Валидация компонентов в состоянии unmounted

• Валидация полей по потере фокуса, сабмите формы и по событию в приложении

• Прокрутка к невалидным полям при сабмите формы

• Валидация нескольких форм одной кнопкой

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

Единообразный API

Все компоненты поддерживают атрибуты, начинающиеся с нижнего подчеркивания _. Такие атрибуты будут преобразованы в имена css-классов:

<L.Div _flexBox> -> <div class="flex-box"></div>

Атрибут className также поддерживается.

В каждый компонент можно передать атрибут theme, который содержит набор css-классов для элементов компонента.

Все компоненты поддерживают атрибуты с суффиксом Render (см. раздел расширяемость).

Поведение и структура события расширены, соблюдается единый стандарт для всех компонентов:

{  Event, // оригинальное событие, сгенерированное React'ом  // событие расширено объектом component, которое содержит данные из компонента component: {  isValid?: boolean, // признак валидности компонента, есть только в onBlurname?: string, // имя формы, к которой привязан компонентvalue: any, // значение компонента // другие свойства объекта (см. API компонента)}}

Названия атрибутов с булевыми значениями начинаются с:

is: isOpen, isValid, isRequired, isDisabled

has: hasCloseButton

should: shouldCorrectValue

Все компоненты поддерживают атрибут ref.

Korus-UI расширяет механизм ref, принятый в React.

Недостатки Korus-UI

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

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

Итоги

Мы подробно рассмотрели основные критерии выбора библиотеки React-компонентов и проанализировали библиотеки Material-UI, Semantic-UI-React, arui-feather (Альфа Банк), yandex-ui, Korus-UI (СберКорус), опираясь на критерии качества.

Вот коротко то, что нужно учесть при выборе библиотеки:

• Собственные нужды и требования

• Кастомизируемость

• Расширяемость

• Типизацию

• Покрытие тестами

• Наличие техподдержки

• Документацию

• Отзывы и активность сообщества библиотеки

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

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

Библиотека Korus-UI выложена в opensource и доступна на GitHub. Это первый шаг для нашей компании в opensource, и мы уверены, что не последний:)

Отдельно хочу выразить благодарность команде разработчиков СберКоруса, отцу иидейному вдохновителю библиотеки Артёму Повольских. Если вам интересно, как устроена фронтенд-разработка в СберКорусе, читайте статью Артёма.

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

В прошлой статье я показал то, как развивался мой проект и, в частности Mark gauntlet. В кратце: это перчатка-наруч, на которой есть радиомодули и разные интерфейсы взаимодействия.
Версия 4.2 скорее всего последняя и я постарался сделать её презентабельной и лёгкой в повторении.

1.Печатные детали

Проектировалось всё в Fusion 360. Детали можно скачать как в slt формате, так и файлом сборки
https://www.thingiverse.com/thing:4727760

Батарейный отсек

В отсек вставляется аккумуляторный бокс 3*18650, сама конструкция одевается на плечо.

Основа и отсек электроники

3 из 4 частей я спаял вместе, а 4 снимается, позволяя надевать основу относительно быстро и надёжно

Перчатка

Этот модуль крепится к любой тканевой перчатке

2.Электроника

Большинство электроники находится на печатных платах

Герберы: https://drive.google.com/file/d/1i3CFKzojWJuONOF4YCz36jZLYSJCyV46/view?usp=sharing

Список необходимых компонентов в таблице: https://docs.google.com/spreadsheets/d/1PZ8kXeQK-clzN3hqWwmkAduVLjoLY-DlqfcQJGO0RUQ/edit?usp=sharing

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

Затем необходимо аккуратно вклеить (можно термоклеем) платы в корпус

3.Программа

Необходимые библиотеки: https://drive.google.com/file/d/18YIRuKPIxHF3aGCWzGyV30Dec9tg4xoR/view?usp=sharing

Код я писал в Visual Studio Code через platformio. Код на гитхабе: https://github.com/Madjogger1202/Mark_GauntletV4.2

Разбор кода и подробности есть в видео: https://youtu.be/YojpGYL2TF0

У меня остались ещё 3 полные пары плат, поэтому если кто-то решит повторить мой проект - могу их выслать (из Китая доставка примерно 1000 руб выйдет, для 1 устройства невыгодно там заказывать).

Если есть какие-либо вопросы по устройству- готов ответить.

Дублирую важные ссылки:

гихаб: https://github.com/Madjogger1202/Mark_GauntletV4.2
библиотеки: https://drive.google.com/file/d/18YIRuKPIxHF3aGCWzGyV30Dec9tg4xoR/view?usp=sharing
thingerverse: https://www.thingiverse.com/thing:4727760
таблица с компонентами и распиновкой: https://docs.google.com/spreadsheets/d/1PZ8kXeQK-clzN3hqWwmkAduVLjoLY-DlqfcQJGO0RUQ/edit?usp=sharing
герберы плат: https://drive.google.com/file/d/1i3CFKzojWJuONOF4YCz36jZLYSJCyV46/view?usp=sharing

Когда говорят Open Source, обычно первые ассоциации это Ричард Столлман и Линус Торвальдс. Но Open Source начался не с них. Когда в 50-х учёные и инженеры писали ПО, например, для IBM 701, они безвозмездно обменивались результатами своего труда и работали над улучшениями программ своих коллег. Тогда еще не было проприетарного (закрытого) ПО, но Open Source проекты уже были. Это было задолго до Столлмана и Торвальдса.В истории Open Source было много интересного: программы для Оборонного калькулятора, коммерциализация UNIX, письмо Билла Гейтса,манифест GNU, Linux и миллиардные сделки покупок Open Source компаний. Мы попробовали разобраться в истории и узнать с чего начался Open Source, какие события способствовали его развитию и почему без Open Source IT не был бы таким, какой он есть.

Если вам интересен Open Source, то, возможно, наш взгляд на историю тоже будет занимателен.

Что такое Open Source для тех, кто совсем не слышал

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

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

Примерно так можно представить себе Open Source ПО.

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

Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.

В определении на Open Source Initiative указано, что Open Source Software (OSS) это ПО, исходники которого доступны для просмотра и изменения. На основе исходного кода можно создавать свои модификации ПО, а также свободно распространять и продавать. OSS это, в первую очередь, про распространение, свободу использования, а не про деньги, потому что OSS может быть и платным, и бесплатным.

Предпосылки свободного ПО: всё началось с калькулятора

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

С 1952 по 1955 компания IBM стала выпускать IBM 701. Это первая коммерчески доступная ЭВМ, которая производилась серийно. Аппараты сдавали в аренду научным институтам, военным компаниям и государственным предприятиям. Физическим лицам не давали, да и стоило это космических денег от 12 до 20 тыс долларов в месяц или больше 100 тыс современных.

Выпуск этой модели первая точка отсчета в истории. Всё потому, что в комплекте с компьютером было только железо никакой ОС и программ. Все программы ученые и инженеры писали сами и делились с коллегами из других компаний, у которых была такая же ЭВМ. Можно сказать, что IBM 701 это первые компьютеры, к которым начали писать свободно распространяемое ПО.

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

За несколько лет для 701 и его потомков семисотой серии успели наработать достаточно большую базу ПО:

• Компиляторы РАСТ, которые использовали методы хеширования (в том числе для 704. Их совместно разработали компания PACT (военный подрядчик) и IBM.

• ОС SOS Share Operating System. Это примитивная ОС, которая основана на разработках General Motors.

• Появились языки программирования Interlisp, UCI Lisp и высокоуровневый ЯП Speedcoding для IBM 701, который написал Джон Бэкус для облегчения работы с ассемблером. Для IBM 704 он же разработал FORTRAN и компилятор (1956).

IBM 701 подтолкнул рынок к разработке других коммерческих ЭВМ. Например, появился Bendix G-15 (1956) с массой всего 450 кг, Librascope LGP-30 (1956) или первый мини-компьютер PDP-1 (1960) для одного оператора. А когда компания в 1965 выпустила PDP-8, он стал хитом. Это первый коммерчески успешный мини-компьютер и продавался тысячами предприятиям и научным лабораториям: небольшой, быстрый и стоил всего 18 000 долларов.

Рождение, рассвет и коммерциализация UNIX

Моделей коммерческих компьютеров было достаточно, они стали появляться у любителей, рынок рос. Но у всех ПК был один недостаток нет ПО. Под каждую модель компьютера ОС писали с нуля. Компании-производители создавали каждый свою операционную систему, например, BESYS, Compatible Time-Sharing System или CP/CMS.

Из всех ОС нас больше интересует BESYS. Ее создала Bell Labs для IBM 7090 и IBM 7094. На основе этой ОС с 1965 по 1969 MIT, Bell Labs и General Electrics, разрабатывали ОС Multics. Это должна была быть инновационная ОС: централизованная файловая система с иерархическим деревом, разделение памяти процессов, виртуальная память, динамическое связывание и другие фишки. Но что-то пошло не так: работа затянулась, возникли разногласия и компания Bell Labs покинула проект.

Но два сотрудника компании Кен Томпсон и Деннис Ритчи решили переиспользовать модульный дизайн Multics и написать не её основе другую ОС.

Первую версию ОС Томпсон написал в отпуске на домашнем PDP-7, презентовал руководству и получил команду разработчиков. Проект получил название UNIX.

Примечание. Полное описание системы и историю на русском можно прочитать в учебном пособии Операционная система UNIX.

Только через 4 года (1973) систему вывели в свет с открытым кодом. Неожиданно она начала захватывать рынок. На это были причины:

Уже существовал рынок программ. Все модели семисотых IBM после 701 поставлялись в комплекте с ПО, и в том числе и продавались физическим лицам. Цена, естественно, была включена в стоимость железа. Но под давлением антимонопольных регуляторов в 1969 году начала продавать ПО отдельно. ОС UNIX здесь пришелся как нельзя кстати.

Небольшая цена. За Bell Labs тоже следили регуляторы. Компания принадлежала гигантам телекома AT&T и Western Electric и на них всех распространялось антимонопольное законодательство. Поэтому на UNIX нельзя было завышать цены ОС продавалась по цене не намного выше себестоимости физической копии.

Ориентация на массовость. UNIX изначально разрабатывался именно для персональных машин, например, для PDP-11, которых выпустили 170 тыс. ОС сразу была нацелена на массовый рынок любителей.

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

Переносимость. UNIX было не сложно перенести с одного ПК на другой. Поэтому рабочие версии UNIX под новые процессоры появлялись быстро.

Но UNIX уже не была свободным ПО: пользователи не имели права делиться или менять исходный код. Однако, благодаря тому, что AT&T была монополией, компания была обязана предоставлять исходный код (с некоторыми ограничениями) разным университетам. Один из университет Калифорнийский университет в Беркли, который начал заниматься улучшениями ОС. Так получилась собственная университетская ОС BSD Berkley Software Distribution.

В первой версии BSD содержался доработанный компилятор языка Pascal, текстовый редактор Ex, а апдейты из BSD переносили в UNIX. BSD был лучше, постоянно обновлялся, в нём появлялись передовые сетевые технологии. Но когда университет стал продавать коммерческие лицензии BSD от 750 до 1000 долларов, корпорация AT&T поняла, что теряет прибыль и в 1979 году ограничила распространение исходного кода ОС. Позже, в 1983 году Bell Labs отделилась от AT&T, и антимонопольные законы уже не мешали коммерциализировать UNIX. Цена ОС выросла теперь она стоила тысячи и десятки тысяч долларов.

Проприетарное ПО и Гейтс

Превратить UNIX полностью в коммерческую ОС у Bell Labs получилось, потому что примерно в то же время, что родился UNIX, разработчики ПО все больше начинают защищать авторские права на свои технологии. Когда всё начиналось с IBM 701, за ОС, компиляторы, языки и программы никто не брал деньги и не требовал авторских отчислений. Все ЭВМ содержались в лабораториях, компаниях, научных центрах в академической среде, где информация распространялась свободно.

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

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

Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.

В 1975 году Билл Гейтс и Пол Аллен разработали интерпретатор языка Basic для тогда еще нового персонального компьютера Altair 8800 от компании MITS. Как ни странно, но интерпретатор работал, MITS заключила контракт с Алленом и еще тогда студентом Гейтсом. По контракту они получали отчисления за проданные копии BASIC: от 30 до 60 долларов. Цена на копию программы начиналась с 500 долларов, тогда как железо могло стоить меньше сотни.

Возможно, покупатели компьютеров не хотели платить в разы больше за ПО, чем за железо, потому что компьютеры продавались тысячами, а BASIC сотнями. Тогда в 1976 году Билл опубликовал своё знаменитое Открытое письмо энтузиастам компьютерного клуба.

В письме было много обвинений в краже ПО (прим: дальше вольный перевод).

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

Большинство из вас воры, вы платите за железо без вопросов, но почему-то думаете, что софт можно копировать друг у друга бесконечно! Вам плевать, платят ли за его разработку программистам. Своим воровством вы препятствуете появлению хорошего софта, потому что никто не хочет заниматься профессиональным программированием бесплатноКто из вас согласен потратить три года на то, чтобы написать программу, отловить все баги, задокументировать проект и раздать все бесплатно? При этом среди вас есть те, кто перепродает наш BASICОни поганят имя компьютерщиков-энтузиастов и должны быть изгнаны из клуба на первом же собрании, где они появятся!

Всё закончилось в 1983. Apple Computer, Inc. подала иск к компании Franklin Computer Corp. Вторая просто скопировала Apple II и ОС и продавала. Apple это не понравилось и они подали в суд. Суд первой инстанции не удовлетворил иск, зато апелляционный подтвердил, что на всё ПО распространяется авторское право. С того момента проприетарный мир победил. Но он же и породил мир Open Source.

Движение свободного ПО, Ричард Столлман и GNU

В 1971 году Ричард Столлман учился в Гарварде и присоединился к лаборатории искусственного интеллекта (AI Lab) при MIT. В процессе разработки ПО всё ещё чувствовался дух товарищества, а до письма Гейтса было целых 5 лет. Столлман отлично вписался и поучаствовал в работе над свободным ПО, например, над EMACS текстовым редактором для миникомпьютеров семейства PDP.

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

Ричард Столлман, основатель проекта GNU.

Когда машина проприетарного ПО начала заводиться (начало 80-х) лаборатория закрылась: появилось NDA, сотрудничества все меньше, разработчики уходят в частные компании и даже создатель версии EMACS для UNIX в 1983 году продал её коммерческому дистрибьютору. Но Столлман считал, что людям необходима свобода решений и информации, свобода менять и улучшать ПО, возможность делиться.

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

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

Ричард Столлман, основатель проекта GNU.

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

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

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

Так, в декабре 1984, появился проект GNU. В январе 1984 Столлман увольняется из MIT и погружается в работу. Увольнение было необходимо, чтобы институт не смог предъявить права на разработки. Столлман решил использовать UNIX в качестве основы, чтобы она была переносима и чтобы пользователи ОС могли легко перейти на новую.

Само название GNU это уже хак. Это рекурсивная аббревиатура GNUs Not UNIXЭто имя означает, что я фактически сделал копию коммерческой системы, но это не была она сама. Свою систему я писал, конечно, с нуля, потому что кодом UNIX нельзя было делиться и он был совершенно бесполезен

Ричард Столлман, основатель проекта GNU.

Юридические нюансы и лицензии

Кроме системы GNU Ричард и энтузиасты работали над философской и юридической стороной свободного ПО:

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

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

• Опубликовали манифестGNU.

Для финансирования работы, Столлман в 1985 году основал Free Software Foundation (FSF). Это благотворительная организация, которая занимается развитием свободного ПО. Например, сотрудники ФСПО написали библиотеку GSL и командный интерпретатора BASH.

Чтобы ПО оставалось свободным, нужно была юридическая защита. Поэтому к 1989году была создана первая версия лицензии GPL General Public License. Переводится как Универсальная общественная лицензия GNU. По замыслу, она должна защитить свободу всех пользователей программ, дать права на копирование, модификацию и распространение (в том числе коммерческое) программ. Кроме того, Ричард добавил в лицензию авторское лево, в противовес авторскому праву, по которому пользователи всех производных программ также получат все оригинальные права.

GPL это одна из немногих лицензий, написанных с позиции сообщества, не ставящая во главу угла защиту интересов компаний или правительственных грантов, как в MIT, например. Но это не просто лицензия, а целая философия, которая повлияла на определение Open Source

Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.

Эта первая каноничная лицензия на свободное ПО. Но принцип авторского лева приняли не все и впоследствии появились другие лицензии, которые позволяют использовать свободное ПО в проприетарном, например, лицензия MIT от Массачусетского технологического института или лицензия BSD от Калифорнийского университета в Беркли (с несколькими вариациями).

В 1991 году появилась новый вариант GPL LGPL (GNU Lesser General Public License). ПО с этой лицензией можно добавлять в проприетарный софт если это независимый продукт и он отличается от оригинала.

Linux и GNU

Обычно про Ричарда Столлмана принято говорить, что он прежде всего великий философ, а меня воспринимают, как инженера, который воплощает его идею

Линус Торвальдс, создатель ядра Linux

UNIX состоял из разных модулей подпрограмм. Чтобы создать полный аналог ОС нужно было заменять каждый модуль один за другим: командные оболочки, ассемблеры, компиляторы, интерпретаторы, отладчики, текстовые редакторы, почтовые программы. Ричард написал анонс, просьбу о помощи, и стал ее получать.

К 1991 году заменили практически все модули, некоторые из которых стали использоваться вне ОС, например, GCC, GNUDebugger и Emacs. Но в системе не хватало ядраоперационнойсистемы, а проект GNUHurd по разработке ядра не развивался.

В 1991 Линус Торвальдс выпустил ядро Linux с открытым кодом, а в 1992 лицензировал ядро по GPL. Linux, также как и GNU, использовал для основы UNIX. Это и привлекло к проекту сначала внимание любителей, а потом и Ричарда.

Народ в интернете скачивал компоненты GNU и запускал их на ядре Linux. В конце концов у них получалась ОС, которую они называли Linux

Ричард Столлман, основатель проекта GNU.

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

Собор и Базар и Mozilla

В 1997 году уже была готова версия 2.1 ядра Linux на 800 тыс строк кода. Системой пользовалось уже 3, 5 млн человек. В это время Эрик Реймонд написал эссе Собор и Базар где демонстрирует два противоположных подхода к разработке.

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

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

Конгресс Linux в 1997 году был первым местом, где я представил свое эссе публично. Одним из тех, кто его тогда услышал был Тим ОРайли. Он решил, что мой текст был довольно интригующим и предложил выступить на конференции Perl. А уже на той конференции кто-то из Netscape послушал моё эссе и рассказал о нём в компании. И вот тогда там загорелся огонёк

Эрик Реймонд, автор Собор и Базар.

Примечание. Тим ОРайли один из идеологов движения Open Source, основатель издательства OReilly и популяризатор термина Open Source Software.

Netscape первая крупная компания, которая пришла в Open Source. В середине 90-х браузер компании Netscape Navigator был одним из самых популярных в мире. Но когда появился Internet Explorer, он стал вытеснять с рынка Netscape, потому что распространялся бесплатно вместе с ОС Windows. Netscape теряла рынок и приходилось снижать цены.

Своей политикой браузер от Microsoft мог получить монополию на стандарты HTTP и HTML, от которых полностью зависит веб. В это время Билл Гейтс финансировал разработчиков HTML и все новшества согласовывались с Microsoft. Если бы Microsoft выдавил бы компанию с рынка, то получил бы монополию на веб, что ударило бы и по другому бизнесу компании разработке серверного ПО.

Примечательно, что Netscape начиналась с того, что основатель компании Джеймс Кларк разослал письма перспективным инженерам из научного мира. Его предложение состояло в том, чтобы совместить научную работу и зарабатывание денег. Первый сотрудник компании аспирант-программист из университета штата Иллинойс Марк Андрессен, автор первого в мире веб-браузера Mosaic. Это, а также агрессия со стороны Microsoft, возможно, и стало причинами заинтересованности основателя компании произведением Собор и Базар. В итоге в Netscape приняли решение в 1998 открыть исходный код своего браузера.

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

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

Фрэнк Хеккер, в то время инженер компании Netscape.

В 1999 компании не стало, а бесплатный Explorer забрал 90% рынка. Но исходный код браузера стал основой для одного из самых популярных браузеров в мире MozillaFirefox. Забавно, что браузер Netscape вытеснил с рынка Internet Explorer, а уже его обогнал MozillaFirefox.

Рождение термина Open Source

После события с Netscape, несколько человек решили, что необходимо придумать замену термина свободное ПО, чтобы убратьассоциации с чем-то дешевым, непонятным, бесплатным и никому не нужным. Чтобы поменять эту парадигму в 1998 в офисе компании VA Linux Systems встретились:

• Эрик Реймонд, автор Собор и Базар;

• Ларри Августин, доктор наук, со-основатель и генеральный директор VA Linux Systems;

• Кристин Питерсон (присутствовала по телефону);

• Джон Хол;

• Тод Андерсон;

• Сэм Окланд (тогда сотрудник VA).

Они и придумали замену термину свободное ПО Open Source, чтобы сменить парадигму бесплатности на доступность.

Мы приняли решение, что нам нужен некий экзаменационный лист, который бы чётко определял, что такое Open Source. В результате мы пришли к документу, который называется Определение Open Source. Он вырос из путеводителя по Debian, который написал Брюс Перенс

Эрик Реймонд, автор Собор и Базар.

Чтобы закрепить новую парадигму Эрик и Брюс написали Определение Open Source, основываясь на политике Debian. В него входят 10 правил, которые и определяют текущее развитие движения. В том же 1998 они основали организацию Open Source Initiative (OSI), которая занимается популяризацией Open Source. Можно сказать, что с этого момента и возник Open Source.

Примечание. OSI и FSF пошли разными путями. Во второй больше внимания на free на свободы. Для OSI основной термин Open Source Software.

Настоящее свободного ПО

Мне кажется, что коммерциализация важна. Мы хотим чтобы наш софт был мейнстримом

Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.

Проекты GNU и ядро Linux стали основой на которой выросли многие другие продукты и проекты. А поступок компании Netscape привлёк внимание людей и компаний к движению свободного ПО и стал одной из причин того, что сейчас IT-гиганты активно развивают свободное ПО и вкладываются в Open Source компании. Всё это вместе привело к тому, что ничто не мешало (и не мешает) развиваться Open Source в коммерческом направлении.

Debian. Этот проект полностью основан на философии GNU и связан с фондом свободного ПО, от которого также получал финансирование.

Apache. Apache сегодня воспринимают, как Apache Software Foundation большую компанию, которая поддерживает много OSS-проектов. Но компания начинала с веб-сервера Apache, очень популярного в свое время. Программа предрешила популярность Linux для веб-серверов. В 1993 году когда появился Apache, рынок интернет-провайдеров стал расти огромными темпами благодаря тому, что Linux и Apache выгоднее для бизнеса, чем проприетарное ПО.

Gnome. Разработка графической среды Gnome привлекла к GNU/Linux пользователей, которые раньше и не задумывались об Open Source ПО. Теперь ОС можно было пользоваться всем, вне зависимости от уровня технических знаний.

RedHat. Возникла в 1995 году и выпускала продукты на основе свободного ПО, ОС Red Hat Linux, занималась технической поддержкой и обучением системных администраторов и разработчиков. Red Hat это пример компании, вся деятельность которой основывалась на открытом ПО. Она была очень успешной: на пике карьеры в ней работало 3 500 сотрудников и она была включена в S&P500. В 2018 году компанию купила IBM.

Без Linux и открытого ПО не было бы Google. Сейчас корпорация поддерживает 2000 Open Source проектов, среди которых TensorFlow, Go и Kubernetes.

В 2001 Oracle обратила внимание на Linux, как важную платформу для баз данных, и опубликовала под лицензией GPL OOCFS2 для Linux и перевела часть внутренних систем на Linux. Это помогло закрепить успех Open Source в сфере баз данных. Сейчас Oracle активно участвует в проектах Java, Linux, Kubernetes.

Microsoft признали ошибку в том, что относились к Open Source предвзято, купила GitHub, вывела .NET Core в Open Source и сейчас активно принимает участие в развитие открытых проектов, например, Linux.

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

• Участие в Open Source проектах привлекает внимание к своим проектам, привлекает энтузиастов, что помогает развивать экосистему вокруг продуктов.

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

• Банально, но скупка Open Source компаний позволяет удерживать создателей проектов и обеспечивать поддержку, а значит работоспособность ПО.

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

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

Из всей истории наша главная мысль в том, что Open Source важная часть современного интернета и IT. Без Open Source или свободного ПО, как его предшественников, не существовало бы интернета, веба и IT, как он есть.

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

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

Итак, опустив голову, я целыми днями придумывал нечто, что было бы лучшим кеширующим кодом Java из всех, что я видел! Я придумал сложные алгоритмы вызова, хранения, пейджинга и удаления данных для одного юзкейса. После 5 дней и ночей тяжёлого труда я гордо встретил своего ведущего разработчика и познакомил его с моим кодом; я одурачил его великолепием алгоритмов.

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

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

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

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

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

Этот урок напомнил мне о недавнем разговоре с молодым разработчиком, представившим проблему с использованием кода в RedHat OpenShift (предупреждаю: я работаю в Red Hat). Во всех деталях он объяснил, что написал множество микросервисов, чтобы сидеть перед множеством API, которые читают данные из различных источников и манипулируют ими перед отправкой в различные конечные точки. Он был очень горд своим множеством микросервисов, которые разработал, чтобы решить проблему. Там были агрегаторы, трансляторы и другие паттерны.

Я выслушал и вздохнул

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

Не стройте микросервисы ради микросервисов!

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

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

Я большой поклонник Apache Camel как в смысле интегратора, так и в смысле большого успеха сообщества Open Source. История утверждает, что Camel появился из разговора Грегори Хофа и Джеймса Стрейкена. Грегор написал библию интеграции Enterprise Integration Patterns, книгу с проектами общих задач интеграции в виде набора шаблонов так что вам не нужно изобретать одни и те же архитектурные шаблоны.

Джеймс, разработчик Open Source и основатель языка Groovy, и Грегор беседовали на конференции, и Джеймс подумал, что было бы неплохо создать переиспользуемые реализации этих шаблонов на Java так что вам не нужно продолжать писать один и тот же код, когда необходимо что-то сделать! Apache Camel родился из этой беседы как набор реализующих шаблоны интеграции библиотек.

Вернёмся к недавнему разговору с младшим разработчиком

Итак, мы взглянули на Red Hat Integration, которая представляет собой Apache Camel и кучу других вещей для развёртывания и запуска сервисов интеграции. Я сказал младшему разработчику, что он не только может делать всё, что ему нужно, но и подогнать всё в его архитектуру микросервисов и, глядя на некоторые новые разработки, такие как Camel K, он также может сервировать свои микросервисы бессерверно [have his microservices servederr, serverless! заставить работать свои микросервисы с помощью технологии serverless, бессерверно].

Бессерверная интеграция микросервисов

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

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

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

Что такое Apache Camel?

Ок, я расскажу быстро, если вы не сталкивались с Apache Camel, то это инструмент потрясающей красоты, который по-настоящему упрощает интеграцию и соединение сотен разных вещей:

Бросим быстрый взгляд на Apache Camel.

1. Он предоставляет более 50 паттернов интеграции.

2. Имеет более 350 коннекторов.

3. Он прекрасен.

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

Компоненты FROM и TO или адаптеры соединяют технологии от нативных сервисов AWS, файлов CSV и SAP до реактивных потоков и коннекторов Kafka их больше трёхсот пятидесяти.

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

Вот мощь Open Source

Вот что обычно происходит: разработчик использует Camel, и плагина, в котором он нуждается, в Camel ещё нет. Итак, разработчик пишет компонент, удовлетворяющий его требованиям. Будучи порядочным гражданином страны Open Source, разработчик радует сообщество Camel вносит свой компонент в исходный код Camel, и этот компонент включается в следующий выпуск Camel. Теперь, когда компонент нужен вам, не нужно создавать его заново это потрясающе!

Множество источников могут помочь вам с Camel. Один из лучших книга Клауса Ибсона и Джонатана Энсти, Camel in Action библия Camel. Джеймс Стрейкен часто говорил, что он изобрёл Camel, но Клаус заставил инструмент работать. Кроме того, взгляните на блестящие статьи Тома Донахью о Camel.

А как же Camel К?

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

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

А вот сервис комплиментов Grant Codes: complimentr.com, который возвращает приятные слова, чтобы поднять настроение.

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

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

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

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

У меня есть кластер kubernetes, поэтому я сделаю бота с помощью Camel K и воспользуюсь Red Hat OpenShift и Camel K Operator, чтобы всё настроить.

Вот, что нужно сделать:

1. Загрузить CLI Camel K.

2. Установить Camel K Operator.

3. Запустить мой код.

Загрузите Camel K CLI

Об этом есть много статей и документации, поэтому я не буду вдаваться в кучу подробностей, но Camel K CLI (или kamel) это, по сути, CLI взаимодействия с вашей платформой Kubernetes (или, точнее, с пользовательскими ресурсами Camel K на платформе) для развёртывания интеграций (есть также плагины для VSCode).

CLI позволяет установить операторы Camel K, запустить интеграции в режиме интерактивной разработки (с обновлениями запущенного кода интеграции на лету) и т. д.

Установка Camel K Operator

В Camel K есть ряд операторов Kubernetes, чтобы создавать, развёртывать и запускать интеграции. Весь смысл операторов Kubernetes заключается в том, чтобы абстрагировать сложности всего того, что работает на платформе, и Camel K справляется великолепно! Так что просто возьмите и установите оператор из CLI, используя командную строку:

Или, если вы работаете в Openshift, откройте вкладку Operators, чтобы установить операторы.

Запускам мой код

После установки я могу отправить код интеграции на свою работающую платформу OpenShift из IDE или из командной строки.

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

from("telegram:bots?authorizationToken=[YOUR TOKEN])

Если я добавлю простое логирование, чтобы увидеть, как работает маршрут:

from("telegram:bots?authorizationToken=[YOUR TOKEN]").to("log:bots")

То на выходе всего пара строк кода. Сохранив их в файле hello.groovy, я получу скрипт groovy, им можно воспользоваться в качестве интеграции CamelK, которая подключится к моему telegram-боту и будет логировать всё, что я напечатаю!

Запуск hello.groovy

Здесь начинается нечто удивительное. Я хочу, чтобы мой двухстрочный скрипт groovy развёртывался и запускался как масштабируемый интеграционный компонент. Вот что такое Camel К! Из командной строки я запускаю простую команду:

С помощью команды run я превратил свой двухстрочный скрипт groovy в контейнер, развёрнутый и работающий как маршрут Apache Camel на моём кластере OpenShift.

Зачем флаг --dev

Добавив флаг --dev, я оказался в странном мире, где я могу изменить свой файл hello.groovy, и изменения отразятся в кластере OpenShift! Опция --dev сильно упрощает разработку.

Бот целиком

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

from("telegram:bots?authorizationToken=[YOUR TOKEN]").setHeader("USER", body()).to("https://complimentr.com/api?asGET=true").transform().jsonpath("\$.compliment").setBody(simple("\${body} \${in.header.USER}")).to("telegram:bots?authorizationToken=[YOUR TOKEN]")

• Чтобы получить сообщения из канала Telegram, я использую компонент Camel Telegram.

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

• Вызовите API комплиментов.

• Обратитесь к пользователю по имени.

• Верните комплимент в канал Telegram.

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

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

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

Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодомHABR, который даст еще +10% скидки на обучение.

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Специально к старту нового потока курса Fullstack-разработчик на Python, представляем небольшой авторский обзор кроссплатформенного инструмента визуализации многопоточных программ VizTracer. У VizTracer 57 форков и 841 звезд на Github. Настраиваемые события, отчёты в HTML, детальная информация о функциях с их исходным кодом, простота применения, отсутствие зависимостей и малый оверхед превращают VizTracer в мастхэв Python-разработчика.

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

В Python вариантов конкурентности много. Самый распространённый, вероятно, многопоточность, которой добиваются с помощью модуля threading и несколько процессов с помощью модулей myltiprocessing и subprocess, а также недавно появившийся способ async из модуля asyncio. До появления VizTracer в инструментах, использующих эти техники в целях анализа программ, был пробел.

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

Попробуем с простой задачей

Определим, являются ли числа в массиве простыми, и вернём массив логических значений. Вот простое решение:

def is_prime(n):    for i in range(2, n):        if n % i == 0:            return False    return Truedef get_prime_arr(arr):    return [is_prime(elem) for elem in arr]

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

if __name__ == "__main__":    num_arr = [random.randint(100, 10000) for _ in range(6000)]    get_prime_arr(num_arr)

Выполняем команду:

viz_tracer my_program.py

Отчёт стека вызовов показывает, что выполнение кода заняло 140 мс, а большую часть времени заняло выполнение get_prime_arr.

Здесь на каждом элементе массива выполняется функция is_prime. Это ожидаемо и не интересно, если VizTracer вам знаком.

Теперь попробуем многопоточную программу

Сделаем то же самое в программе с несколькими потоками:

if __name__ == "__main__":    num_arr = [random.randint(100, 10000) for i in range(2000)]    thread1 = Thread(target=get_prime_arr, args=(num_arr,))    thread2 = Thread(target=get_prime_arr, args=(num_arr,))    thread3 = Thread(target=get_prime_arr, args=(num_arr,))    thread1.start()    thread2.start()    thread3.start()    thread1.join()    thread2.join()    thread3.join()

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

Если вы знакомы с Python Global Lock (GIL), то можете ожидать, что программа не станет быстрее: из-за оверхеда она выполняется немного дольше 140 мс, однако можно наблюдать конкурентность множества потоков:

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

Попробуем поработать с multiprocessing

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

if __name__ == "__main__":    num_arr = [random.randint(100, 10000) for _ in range(2000)]       p1 = Process(target=get_prime_arr, args=(num_arr,))    p2 = Process(target=get_prime_arr, args=(num_arr,))    p3 = Process(target=get_prime_arr, args=(num_arr,))    p1.start()    p2.start()    p3.start()    p1.join()    p2.join()    p3.join()

Чтобы запустить его с помощью VizTracer, понадобится дополнительный аргумент:

viztracer --log_multiprocess my_program.py

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

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

Однако многопоточность в Python не бесполезна. Например, для вычислительно-интенсивных программ и программ с интенсивным вводом-выводом, при помощи sleep можно имитировать задержку ввода-вывода:

def io_task():    time.sleep(0.01)

Попробуем в однопоточной программе с одной задачей:

if __name__ == "__main__":    for _ in range(3):        io_task()

.

Вся программа занимает 30 мс; ничего особенного. Теперь воспользуемся многопоточностью:

if __name__ == "__main__":    thread1 = Thread(target=io_task)    thread2 = Thread(target=io_task)    thread3 = Thread(target=io_task)    thread1.start()    thread2.start()    thread3.start()    thread1.join()    thread2.join()    thread3.join()

Выполнение занимает 10 мс: ясно, что все потоки работали одновременно и повысили производительность.

Теперь поработаем с asyncio

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

import asyncioasync def io_task():    await asyncio.sleep(0.01)async def main():    t1 = asyncio.create_task(io_task())    t2 = asyncio.create_task(io_task())    t3 = asyncio.create_task(io_task())    await t1    await t2    await t3if __name__ == "__main__":    asyncio.run(main())

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

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

viztracer --log_async my_program.py

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

На временной шкале показывается, когда задачи создавались и выполнялись. Task-1 была сопрограммой mail(), которая создаёт другие задачи. Задачи 2, 3 и 4 выполняли io_task и sleep, а потом ждали пробуждения. Как показывает график, задачи не перекрывают друг друга, поскольку программа однопоточная, и VizTracer визуализировал её так, чтобы она была понятной. Чтобы сделать код интереснее, добавим вызов time.sleep, чтобы заблокировать асинхронный цикл:

async def io_task():    time.sleep(0.01)    await asyncio.sleep(0.01)

Программа заняла намного больше времени (40 мс) и задачи заняли свои места в асинхронном планировщике. Это поведение очень полезно для диагностики проблем поведения и производительности в асинхронных программах.

Смотрите на происходящее с помощью VizTracer

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

Исходный код VizTracer открыт под лицензией Apache 2.0, поддерживаются все операционные системы Linux , MacOS, Windows. Вы можете узнать больше о его функциях и увидеть исходный код в репозитории VizTracer на Github. А освоить разработку на Python и стать Fullstack-разработчиком на нашем специализированном курсе.

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

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

WebGL 2.0 вышел в далёком 2017ом году, принёс графический стек OpenGL ES 3.0 (2012го года), и, казалось бы, все современные браузеры давно должны были его поддерживать. Однако, среди лидеров затесались отстающие, и пользователи Safari до сих пор (начало 2021го) вынуждены ограничиваться возможностями WebGL 1.0, опубликованным в 2011ом году на основе OpenGL ES 2.0.

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

Браузерные технологии оказались ещё более инертными - в то время как Android устройства уже давно поддерживают OpenGL ES 3.2 с вычислительными шейдерами, внедряют поддержку Vulkan, а разработчики web-стандартов готовят WebGPU, обычному разработчику по-прежнему доступен устаревший уже на момент публикации WebGL 2.0, а то и вовсе WebGL 1.0 каменного века

Некоторое время назад, графический движок C++ фреймворка Open CASCADE Technology (OCCT) обзавёлся поддержкой PBR (основанной на физике освещению) модели материалов металл-шероховатость (metal-roughness). Продвижение формата glTF 2.0, известного как JPEG для 3D, способствовало выводу этой модели материалов как стандарта обмена между графическими движками.

PBR освещение требует существенно больше вычислительных ресурсов по сравнению с устаревшими эмпирическими моделями Гуро/Фонга времён OpenGL 1.1. Поэтому неудивительно, что реализация PBR в движке была изначально написана на основе относительно современного графического стека OpenGL 3.0 (выпущенного в 2008ом году!) и адаптированного под его мобильную версию OpenGL ES 3.0.

Однако тестирование графического движка в браузерах (в виде модуля WebAssembly) выявило уже озвученную аномалию - браузерный движок WebKit в основе одного из самых распространённых браузеров Safari до сих пор полноценно не поддерживает WebGL 2.0! И если пользователи Safari на macOS могут отделаться лёгким шоком и установить браузер посовременнее, то пользователи iOS такой возможности лишены политикой Apple. В AppStore можно найти альтернативные браузеры, но к сожалению все они основаны на том же движке WebKit, встроенном в систему, что и Safari - в силу ограничений магазина AppStore у разработчиков других браузеров просто нет выбора.

При этом вполне очевидно, что ограничение WebGL 1.0 связаны именно с программной стороной, ведь графические процессоры мобильных устройств Apple давно считаются относительно производительными, да и OpenGL ES 3.0 поддерживается на iOS нативными приложениями.

Более того, уже некоторое продолжительное время Safari имеет опцию, активирующую экспериментальную поддержку WebGL 2.0. На практике, экспериментальная опция всё ещё не проходит ряд важных тестов, хотя прогресс на лицо - WebGL 2.0 уже почти работает в iOS 14. И действительно, с локальным патчем для Emscripten, обходящим баги реализации экспериментального WebGL 2.0, мне удалось увидеть пример OCCT с работающим PBR освещением:

 function _glUniform4fv(location, count, value) {   GL.validateGLObjectID(GL.uniforms, location, 'glUniform4fv', 'location');   if (GL.currentContext.version >= 2) {      // WebGL 2 provides new garbage-free entry points to call to WebGL.      // Use those always when possible.-     GLctx.uniform4fv(GL.uniforms[location], HEAPF32, value>>2, count*4);-     return;+     //GLctx.uniform4fv(GL.uniforms[location], HEAPF32, value>>2, count*4);+     //return;   }...

Мини-вызов: OCCT PBR на WebGL 1.0

Несмотря на многочисленные свидетельства того, что Safari вот-вот обзаведётся поддержкой WebGL 2.0, текущие пользователи по-прежнему страдают от его отсутствия (ну или радуются экономии заряда батареи). Некоторые графические движки прямо заявляют, что не поддерживают PBR освещение без WebGL 2.0, однако мне стало любопытно, реалистично ли запустить PBR на WebGL 1.0 и с какими ограничениями.

Впрочем, конечной, целью была выбрана не поддержка голого WebGL 1.0, а запуск PBR на современных устройствах iPad с доступными расширениями WebGL. Вот список таких расширений для устройства iPad 2020 (Apple A12 Bionic) на iOS 14.4 / Safari:

EGLVersion: 1.4 Emscripten EGLEGLVendor: EmscriptenEGLClientAPIs: OpenGL_ESGLvendor: WebKitGLdevice: WebKit WebGLGLunmaskedVendor: Apple Inc.GLunmaskedDevice: Apple GPUGLversion: OpenGL ES 2.0 (WebGL 1.0)GLSL: OpenGL ES GLSL ES 1.00 (WebGL GLSL ES 1.0 (1.0))Max texture size: 16384Max FBO dump size: 16384x16384Max combined texture units: 32Viewport: 1560x1080GLextensions: GL_EXT_blend_minmax GL_EXT_sRGB GL_OES_texture_floatGL_OES_texture_half_float GL_OES_texture_half_float_linearGL_OES_standard_derivatives GL_EXT_shader_texture_lodGL_EXT_texture_filter_anisotropic GL_OES_vertex_array_objectGL_OES_element_index_uint GL_WEBGL_lose_context GL_WEBGL_compressed_texture_astcGL_WEBGL_compressed_texture_etc GL_WEBGL_compressed_texture_etc1GL_WEBKIT_WEBGL_compressed_texture_pvrtc GL_WEBGL_depth_textureGL_ANGLE_instanced_arrays GL_WEBGL_debug_shaders GL_WEBGL_debug_renderer_infoGL_EXT_color_buffer_half_float

Отладка вёб-приложения в мобильном браузере удовольствие весьма сомнительное, поэтому первым делом были подобраны альтернативные конфигурации с WebGL 1.0:

• Отключение WebGL 2.0 в скрытых опциях Firefox.

  • Управляется опцией webgl.enable-webgl2=false на странице about:config.

  • Предоставляет аппаратно-ускоренную реализацию WebGL 1.0, допускающую некоторые отклонения от WebGL 1.0 спецификаций на железе уровня WebGL 2.0.

  • Поддерживает вывод JavaScript консоли.

• Отключение WebGL 2.0 в опциях сборки Emscripten.

  • Управляется флагом сборки MAX_WEBGL_VERSION=1.

  • Предоставляет аппаратно-ускоренную реализацию WebGL 1.0.

  • Поддерживает JavaScript консоль (в десктопных браузерах).

• Отключение аппаратного ускорения в браузерах на движке Chromium в паре с опцией сборки MAX_WEBGL_VERSION=1.

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

  • Поддерживает JavaScript консоль (в десктопных браузерах).

• Сборка Draw Harness на десктопе с опцией OpenGL ES, реализованной библиотекой ANGLE.

  • Использует ту же реализацию OpenGL ES, которую используют десктопные браузеры.

  • Команда vcaps -maxversion 2 0 активирует создание OpenGL ES 2.0 контекста (вместо OpenGL ES 3.0).

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

• Запуск в браузере Safari на macOS.

  • Предоставляет аппаратно-ускоренную реализацию WebGL 1.0.

  • Поведение на Apple M1 (ARM64) очень близко в iPad, но есть расхождения!

  • Поддерживает вывод JavaScript консоли.

• Запуск в браузере Safari на iOS.

  • Предоставляет аппаратно-ускоренную реализацию WebGL 1.0.

  • Нет JavaScript консоли.

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

Наиболее упрямыми реализациями оказались программный WebGL, реализуемый средствами библиотеки ANGLE, а также реализация OpenGL поверх Metal от Apple. Там где CG компилятор NVIDIA не скажет ни слова, драйвер AMD мягко предупредит в логе компиляции шейдера, OpenGL реализация Apple не оставит безобразие без внимания и ошибкой скажет, что такой функции в GLSL 110 нет и появилась она только в GLSL 120!

Портирование кода PBR на WebGL 1.0 было встречено следующими проблемами:

• Загрузка данных PBR таблицы-кеша 128x128 формата GL_RG32F в текстуру формата GL_RG16F.

  • Проблема #1: текстурные форматы GL_RG32F/GL_RG16F не поддерживаются iPad + WebGL 1.0 (расширение GL_EXT_texture_rg недоступно).

  • Проблема #2: текстуры формата GL_RGBA32F не поддерживают фильтрацию на iPad + WebGL 1.0. iPad не поддерживает расширение GL_OES_texture_float_linear, однако нефильтруемые текстуры с плавающей запятой поддерживается через расширение GL_OES_texture_float. В тоже время, iPad поддерживает расширение GL_OES_texture_half_float_linear, так что текстуры с плавающей точкой половинчатой точности поддерживают фильтрацию.

  • Проблема #3: текстуры формата GL_RGBA16F могут быть загружены напрямую из данных плавающей запятой одинарной точности в случае с OpenGL ES 3.0 / WebGL 2.0, однако WebGL 1.0 + GL_OES_texture_half_float не допускает этого.

• Запекание спекулярной PBR карты в текстуру 9x1 GL_RGBA32F.

  • Проблема: в текстуру формата GL_RGBA32F нельзя производить отрисовку через FBO на iPad + WebGL 1.0. iPad не поддерживает расширение WEBGL_color_buffer_float.

• Запекание мип-уровней диффузной PBR кубической текстуры 512x512x6 GL_RGBA8.

  • Проблема: iPad + WebGL 1.0 не допускают отрисовку в мип-уровни, отличные от нулевого (расширение GL_OES_fbo_render_mipmap не поддерживается).

• PBR GLSL программы полагаются на явное задание мип-уровня текстуры, в зависимости от шероховатости материала.

  • Проблема: textureCubeLod() недоступна в GLSL 100 es, но доступна посредством расширения GL_EXT_shader_texture_lod на iPad + WebGL 1.0.

• PBR GLSL программы содержат большие блоки циклов, ветвления и оператор модуля %.

  • Проблема #1: оператор модуля % недоступен в GLSL 100 es, но может быть заменён функцией mod().

  • Проблема #2: GLSL 100 es не предусматривает синтаксиса для инициализации массива констант.

  • Проблема #3: GLSL 100 es не допускает неконстантные выражения для определения индекса (non-constant index expressions).

• Буфер цвета sRGB и кубическая карта окружения.

  • Проблема #1: расширение GL_EXT_sRGB доступно на iPad + WenGL 1.0, но требует иных констант для инициализации, а также запрещает генерацию мип-уровней посредством glGenerateMipmap().

  • Проблема #2: ужасно медленная генерация мип-уровней для sRGB текстур на WebGL 2.0 (5 секунд!).

Поиск решений

Случайное использование нефильтруемые форматы текстур - одна из самых противных проблем в OpenGL. Логи выглядят абсолютно чистыми - ни ошибок glGetError(), ни предупреждений WebGL в консоли, просто на экран выводится некорректный результат. С практической точки зрения, нефильтруемая текстура возвращает нули в GLSL программу, и требуется приличное время для того, чтобы обнаружить источник проблемы.

Загрузка GL_RGBA16F текстуры в случае с WebGL 1.0 + GL_OES_texture_half_float требует программной реализации конвертера 32битных чисел с плавающей запятой в 16битные - ведь центральные процессоры и C/C++ не имеют встроенной поддержки чисел с половинной точностью. OpenGL 3.0 и OpenGL ES 3.0 позволяют избежать этого чудного кода, а вот для поддержки WebGL 1.0 придётся его добавить в приложение. В процессе отладки удалось запечатлеть вот такой забавный эффект при интерпретации GL_RGBA32F данных как массива GL_RGBA16F:

Невозможность отрисовки в текстуру формата GL_RGBA32F стала неприятной проблемой для реализации PBR, так как меньшая точность будет недостаточно для данной текстуры. К счастью, PBR спекулярная карта имеет размер всего 9x1 текселей - можно было бы даже подумать о вычислении значений без помощи OpenGL, если бы это не тянуло за собой необходимость реализовать выборки с фильтрацией из кубической текстуры Вместо этого, следующий подход был реализован: значения с плавающей запятой упаковываются шейдером в текстуру формата 9x3 GL_RGBA8 (по строке на RGB компоненту), затем читаются с посредством glReadPixels(), распаковываются и загружаются в финальную текстуру формата GL_RGBA32F.

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

Без функции textureCubeLod() в шейдере практически невозможно реализовать корректное поведение PBR освещение с разными уровнями шероховатости, но к счастью, все тестируемые реализации WebGL 1.0 поддерживали расширение GL_EXT_shader_texture_lod, активируемое в GLSL шейдере кодом:

+#extension GL_EXT_shader_texture_lod : enable+#define textureCubeLod textureCubeLodEXT

Пара скриншотов внизу показывает как бы выглядели PBR материалы, если просто заменить textureCubeLod() на textureCube(), т.е. на автоматический выбор мип-уровней текстуры вместо ручного на основании шероховатости:

Многочисленные ограничения синтаксиса GLSL 100 es не раз заставляли задумываться о напрасной борьбе с тенью прошлого. И если оператор модуля % легко заменяется на функцию mod(), а прочие ограничения могут ввести в ступор:

• Ранние версии GLSL просто не предусматривали синтаксис для инициализации массива констант:
  > const float aSHBasisFuncCoeffs[9] = float[9] { 0.0, 1.0, 2.0, };

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

• Переменное количество итераций цикла for(;;). Программа запекания PBR текстур задаёт несколько параметров, задающих точность (качество):
  > uniform int uSamplesNum;
> for (int aSampleIter = 0; aSampleIter < uSamplesNum; ++aSampleIter) {}

  • Большее количество выборок увеличивают качество, но требуют более тяжёлых расчётов, поэтому эти параметры были вынесены в настройки, и более того, автоматически калибруются в зависимости от мип-уровня текстуры. Ограничения GLSL 100 es нарушают эту логику - uniform переменная должна быть заменена на константу компиляции. Хотя типичным обходным путём может быть также написание такого цикла:
    > uniform int uSamplesNum;
> int TheMaxSamples = 1024;
> for (int aSampleIter = 0; aSampleIter < TheMaxSamples; ++aSampleIter) {
> if (aSampleIter >= uSamplesNum) { break; }
> }

• Non-constant index expressions are disallowed. Программа запекания PBR карт использует такие конструкции:
  > int anIndex = int(gl_FragCoord.x);
> float aCoef = aSHCosCoeffs[anId] * aSHBasisFuncCoeffs[anId];

  • Ограничения GLSL 100 es приводят к написанию следующего ужасного кода с использованием if/else.
    > if (anId == 0) { aCoef = aSHCosCoeffs[0] * aSHBasisFuncCoeffs[0]; }
> else if (anId == 1) { aCoef = aSHCosCoeffs[1] * aSHBasisFuncCoeffs[1]; }
> else if (anId == 2) { aCoef = aSHCosCoeffs[2] * aSHBasisFuncCoeffs[2]; }

Большинство ограничений языка шейдеров GLSL 100 es являются не более чем эхом графических процессоров прошлого, не поддерживающих ветвление. И хотя синтакс GLSL заделывался на будущее, первая версия требовала написание циклов и условий ветвлений, которые могли быть тривиально раскручены (trivially unrolled) компилятором, т.к. графические процессоры того времени иного варианта просто не поддерживали.

sRGB текстуры

Рендеринг с учётом цветового пространства sRGB важен для корректной цветопередачи. К сожалению, WebGL 1.0 + GL_EXT_sRGB имеет существенное ограничение - невозможность генерации мип-уровней. Это делает поддержку sRGB текстур практически бесполезной, если только не использовать форматы с предварительно подготовленными мип-уровнями. И если в случае обычных текстур мип-уровнями можно пожертвовать (снизится качество картинки), то при запекании PBR карт из кубмапы окружения просто обойтись без мип-уровней уже нельзя.

Но даже в случае с WebGL 2.0, формально поддерживающим генерацию мип-уровней sRGB текстур, данная функциональность реализована чудовищно медленной. Генерация мип-уровней кубмапы размером 2048x2048x6 выполняется 5 секунд на быстром десктопном компьютере! При этом тот же самый код отрабатывает за считанные доли секунд при использовании нативной OpenGL / OpenGL ES реализации вместо браузера.

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

Послесловие

В результате потраченных усилий наконец-то удалось увидеть PBR материалы посредством графического движка OCCT в Safari на iPad c контекстом WebGL 1.0. Конечно, тестируемое устройство относится к относительно новому поколению (iPad 2020, основанному на Apple A12 SoC анонсированной в 2018ом году), но есть надежда на то, что более старые устройства Apple также справятся с задачей.

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

В этом контексте, отказ Microsoft от поддержки устаревших движков вроде Internet Explorer и Microsoft Edge Legacy (базирующимся на не-Chromium движке) ощущается как свежий воздух для вёб-разработчика, измученного проблемами совместимости. Хотя исчезающе малое количество конкурирующих полноценных вёб-движков не может не настораживать (Mozilla Firefox, Chromium, Safari/WebKit) и опасаться за будущее открытых вёб-стандартов в мире, где один браузер станет бесконтрольно доминировать.

Стратегия Apple по удержанию экосистемы iOS под колпаком и не пускать решения конкурентов лишает пользователей системы собственного выбора. Многочисленные слухи свидетельствуют, что измученная экспериментальная поддержка WebGL 2.0 в движке WebKit вот-вот перестанет быть экспериментальной (в том числе благодаря переходу на реализацию OpenGL ES библиотекой ANGLE, которая уже давно используется другими браузерами), хотя сроки, как обычно, остаются неизвестными.

Оригинальную публикацию на английском можно найти здесь.

В наше время в каждом доме по кластеру kubernetes, выкатка приложений в кластер осуществляется по тегу. Образ выкатываемого приложения отправляется тегом в репозиторий проекта Registry GitLab, которое постепенно распухает до невероятных размеров.

Существующие решения

• Решение из коробки

  Идем в проект Settings CI/CD CleanUp policy for tags. Тут можно создать некий шаблон, который под капотом использует Bulk Delete и, в принципе, все не плохо ЕСЛИ у вас куча тегов ссылающихся на один и тот же образ. Но если у вас идет активная разработка и каждый второй тег - это новый образ, этот способ не поможет.

• Решения от community

  1. "Сжечь и перевыкатить"

  2. Ручная либо полу ручная сортировка образов и тегов.

Данные решения мне не понравились, а значит:

Подготовка

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

Настраиваем сборщик мусора GitLab

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

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

sudo gitlab-ctl registry-garbage-collect

Можно освободить еще больше места удалив не используемые слои образов

sudo gitlab-ctl registry-garbage-collect -m

ВНИМАНИЕ: Во время чистки мусора останавливается служба registry, как следствие пользователи не смогут делать push, pull.

Опытные джедаи могут сократить время простоя путем временного перевода registry в режим readonly.

sudo vi /etc/gitlab/gitlab.rb

registry['storage'] = {    'maintenance' => {      'readonly' => {        'enabled' => true      }    }  }

sudo gitlab-ctl reconfigure

по окончанию работ устанавливаем enabled в false и снова sudo gitlab-ctl reconfigure.

Алгоритм чистки

GitLab

Для работы с GitLab нам понадобится GitLab API и токен с правами api + если хотим проверять и чистить приватные репозитории понадобится read_repository и write_registry.

Для получения образов, хранимых в registry GitLab, нужны id проекта и id репозитория в registry.

1. Забираем информацию о проектах через /api/v4/projects, endpoint возвращает список объектов. Полей много, но нас интересует поле id.

2. Фильтруем проекты, которые необходимо исключить.

3. Зная project[id] собираем информацию о репозиториях через /api/v4/projects/{project[id]}/registry/repositories. Тут мы получим список объектов из которых заберем id репозиториев.

4. И, наконец, собираем теги /api/v4/projects/{repo['project_id']}/registry/repositories/{repo['id']}/tags

На выходе список объектов, вот пример одного из них:

{    "location": "mygitlab.abc.ru:3000/dev/my-awsome-app/base:deploy_123",    "name": "deploy_123",    "path": "dev/my-awsome-app/base:deploy_123"  }

Я туда сразу вбрасываю поле del_url, как можно догадаться в нем URL для удаления данного образа.

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

Kubernetes

Для взаимодействия с Kubernetes используется модуль kubernetes. Если вы, также как и я, хотите заново изобрести велосипед - список пользовательских библиотек для разных языков лежит здесь.

Kubernetes хранит историю всех, работающих в нем приложений ее можно посмотреть командой kubectl rollout history <указание на объект>, либо собрать ReplicaSetы и по номеру ревизии определить кто за кем идет. Я использовал второй вариант он также позволит нам забирать любые интересующие нас поля. Из полученной информации я забирал образ, номер ревизии и идентификатор. В качестве идентификатора приложения к которому принадлежит данный replicaset я использовал имя namespace + label app либо для служебных приложений replica_set.spec.template.spec.service_account. Получаем объект поля - идентификаторы приложения, содержимое - образы с ревизиями. Дальше все просто, оставляем по каждому приложению N образов из последних ревизий и оставшиеся образы сбрасываем в одну кучу.

Итог - список образов из Kubernetes, если эти образы есть в GitLab их теги чистить не нужно.

ВНИМАНИЕ: В список не попадут Job и CronJob так как они не имеют ReplicaSet. Чтобы их сохранить можно ручками внести проекты в исключения либо автоматически отфильтровать.

Унифицированного подхода я не придумал, а наша реализация этой фичи останется секретом фирмы :)

"Отделяем зерна от плевел" точнее наоборот...

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

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

Автоматизация написана на python, но это не столь принципиально. Можно значительно сократить размер кода и затраты памяти, если чуть чуть подумать.