Подводный ЦОД Microsoft: пассивное охлаждение, энергия волн и пост-квантовая криптография у берегов Шотландии

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

В 2018 году Microsoft подвела к объекту силовые и оптоволоконные кабели и намеренно затопила. В течение последующих 2 лет под 117-метровой толщей воды внутри цилиндра находились 12 стоек с ИТ-оборудованием обрабатывая рабочие нагрузки по программе Microsoft Azure (лазурный). Подводный центр обработки данных был последним экспериментом в рамках в проекте Natick, который ставил перед собой цель запустить необслуживаемые серверы и выяснить, может ли облако работать под водой. В июле 2020 года пришло время поднять капсулу и оценить результаты.

Проект Natick

Проект получил начало в 2013 году, когда исследователь Microsoft Шон Джеймс (Sean James), ранее служивший подводником ВМС США, написал статью, в которой предлагалось использовать подводные центры обработки данных. В 2014 году компания решила заняться вопросом по-настоящему и собрала команду под руководством Бена Катлера (Ben Cutler). В 2015 году она предприняла первый шаг, запечатав единственную стойку серверов на судне и погрузила ее на мелководье у берегов Калифорнии. Микро-ЦОД надежно работал в течение трех месяцев, прежде чем его подняли для анализа. Это было доказательством предложенной концепции. Видео первого эксперимента.

И вот уже в 2018 году, как было сказано выше «Северные острова» или проект SSDC-002 стал для ЦОДа настоящим испытанием. На этот раз в цилиндре, заполненном инертным газом (азотом) уже было 864 сервера и 27,6 петабайта памяти. Он потреблял в общей сложности 240 кВт, что составляло около 20 кВт на стойку. 

«ЦОД рассчитан на мощность до 900 Вт/U и имеет стойки 42U высотой. Потенциально мы могли подать более 30 кВт на стойку. Система отработала успешно и превзошла все ожидания», – здесь и далее слова Бена Катлера в интервью порталу Data Centre Dynamics (DCD).

SSDC-002 не просто эквивалентен наземным аналогам. По некоторым параметрам проект превосходил их. Microsoft заявила, что оборудование, которое провело два года в подводном центре обработки данных, было в 8 раз надежнее, чем аналогичные серверы, работающие на суше.

Почему морские серверы работают лучше наземных? Как производилось сравнение? И каковы перспективы проекта?

Надежность, рожденная в море

В контейнере нет ничего особенного, по сути, ЦОД был предназначен для использования готового ИТ-оборудования. Более того, оно было даже не новое – серверы были взяты из существующего дата-центра. На них установили только новые SSD накопители для загрузочных дисков и новые жесткие диски для данных. Это было стандартное готовое оборудование.

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

855 из этих серверов были помещены в цистерну на Северных островах и проработали под водой 25 месяцев и восемь дней без обслуживания. Остальные 135 серверов трудились в паре стоек обычного центра обработки данных вместе с оборудованием, на котором работало облако Microsoft Azure.

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

Проект SSDC-002 никогда не обрабатывал данные о клиентах, но он работал так хорошо, что, когда в этом году у него освободилась емкость Microsoft направила ее на борьбу с Covid-19 в рамках проекта Folding@home с тем, чтобы изучить белковые структуры вируса.

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

Через два года подводные серверы, назовем их так, превзошли наземные. Из 135 наземных серверов было потеряно 8. В воде же потеряли 6 из 855. Катлер подчеркивает, что показатели отказов необслуживаемых бывших в употреблении систем несопоставимы вне проекта.

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

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

Как только ЦОД оказался на берегу он был отправлен для анализа партнеру Microsoft в исследовательски центр Naval Group во Франции. 8 серверов, что вышли из строя были изучены наиболее тщательно с помощью сканирующих электронных микроскопов и рентгеновских снимков.

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

Воздействие на окружающую среду

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

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

Это большой плюс – дата-центры могут использовать много воды для охлаждения. И это позволяет развертывать их в любом месте на водных просторах – от Арктики до экватора. Затраты на охлаждение крайне малы, поэтому большая часть мощности направлялась на серверы, что давало эффективность использования энергии (Power Usage Effectiveness, PUE) всего 1,07.

Низкий PUE – это конечно хорошо, но влияет ли SSDC-002 на локальную среду? Вода, которая сбрасывалась в море, на долю градуса теплее той, что поступала из окружающего океана. И это очень небольшой процент воды, который выходит наружу. Так что буквально в нескольких метрах вниз по течению вы уже не сможете почувствовать разницу температур. Рассеивание тепла имеет важное значение, поэтому в данном случае не было никаких вредных локальных эффектов. Более того морским обитателям нравятся такие вещи. Это искусственный риф, который становится хорошим местом для поиска пищи и местом, где можно спрятаться от крупных морских существ.

Хотя использование возобновляемых источников энергии не входило в рамки этого проекта, в Шотландии есть много местных источников зеленой энергии. На Оркнейских островах, где проходили испытания, находится Европейский центр морской энергии – испытательный полигон для производства электроэнергии из волн. Данные электростанции имеют всплески, которые можно использовать, и исследователи фактически арендовали один из источников чистой волновой энергии – SSDC-002 был подключен к сети, как потребитель. 

Когда же новый старт?

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

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

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

В 2017 году Катлер подал патент для Microsoft, описывая подводный центр обработки данных, в котором контейнеры выстроены в линию, как искусственный риф.

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

Проверка атмосферы

Исследователи вставили пробирки в верхней части резервуара для сбора проб воздуха с помощью приборов масс-спектроскопии и газовой хроматографии. Зачем это делать? При отсутствии воздуха, поступающего в резервуар, SSDC-002 представлял уникальную возможность ответить на вопрос, создает ли центр обработки данных собственное загрязнение воздуха. Но это была закрытая среда и не нужно было беспокоиться о каких-либо формах загрязнения, природного или техногенного происхождения. Не нужно было беспокоиться и о кислороде, но, с другой стороны, там находился пластик, покрывающий Ethernet кабели и прочее оборудование, который может выделять пары или газы, изменяя атмосферу.

Перед затоплением SSDC-002 команда Natick уже отработала наилучший способ создания комфортной 100-процентной атмосферы азота для ИТ-оборудования, начиная с обычного земного воздуха, состоящего из 78 процентов азота и 21 процента кислорода. Для первого испытания в Калифорнии команда Natick просто снизила давление в цилиндре, а затем впрыснула азот. Сначала влажность падает, потому что всё лишнее, в том числе и водяной пар заменяется чистым азотом. Но затем, если подождать несколько часов, влажность снова повысится, поскольку такие вещи, как сетевые кабели, содержат влагу.

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

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

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

Задачи на суше

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

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

Ben Cutler
Ben Cutler

 

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

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

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


Публикация подготовлена компанией ITSOFT. Размещение и аренда серверов и стоек в двух ЦОДах в Москве; colocation GPU-ферм и ASIC-майнеров, аренда GPU-серверов. Лицензии связи, SSL-сертификаты. Администрирование серверов и поддержка сайтов.


ссылка на оригинал статьи https://habr.com/ru/company/itsoft/blog/648869/

Security Week 2205: эскалация привилегий в Linux и Windows

Важной новостью прошлой недели стало обнаружение уязвимости в PolKit — открытом ПО, использующемся в большинстве популярных дистрибутивов Linux для контроля пользовательских привилегий. С 2009 года в коде входящей в состав PolKit утилиты pkexec существовала ошибка, вызывающая повреждение памяти. Эксплуатация данной уязвимости — простой и надежный способ получить привилегии root, если у вас уже есть доступ к системе в качестве обычного пользователя.

Технические детали уязвимости приводятся в отчете компании Qualys, а пример эксплуатации уязвимости на скриншоте выше взят из этой публикации. Для распространенных дистрибутивов (как минимум Ubuntu, Debian, Fedora, CentOS) патч был выпущен до публикации информации об уязвимости. Назвали уязвимость по мотивам имени компонента: PwnKit.

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

На прошлой неделе был также опубликован разбор уязвимости CVE-2022-21882 в Microsoft Windows, которая тоже позволяет повысить привилегии в системе. Закрыта проблема была чуть раньше, в составе январского набора патчей Microsoft. Примечательно, что похожую проблему в Win32k уже закрывали в феврале прошлого года. Новый эксплойт по сути является вариантом обхода прошлогоднего патча.

Что еще произошло:

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

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

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


ссылка на оригинал статьи https://habr.com/ru/company/kaspersky/blog/648871/

Экосистема React в 2022 году

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

Мы рассмотрим язык, библиотеки для различных use-кейсов и инструменты которые удобны, полезны, а иногда и необходимы для разработки фронтенда в 2022 году.

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

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

JavaScript → TypeScript

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

IE11 всё

Вторая отличная новость, что мы наконец таки перешагнули бездонную пропасть между Internet Explorer 11 и текущими браузерами. Microsoft официально прекратит поддержку браузера летом 2022 года. Хотя естественно он никуда не изчезнет и будет еще доступен в специальных сборках Windows, а также браузер Edge будет иметь режим IE11, для отображения старых сайтов, но в любом случае крупные проекты уже начали отказ от поддержки IE и это очень радует.

Этот шаг нам дает возможность полноценно пользоваться новыми спецификациями и функциями, а также новыми версиями библиотек, которые основаны на API, не поддерживаемом IE (Mobx, Bootstrap и пр).

Сборщики

Webpack

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

Он обновился до пятой версии, привнеся нам большую производительность и крутые фичи такие как Module Federation

Babel

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

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

Create React App

Приближаясь все ближе к Реакту нельзя забывать основной инструмент для создания проектов — Create React App. Он все также полностью снимает с нас вопрос о настройке проекта и конфигурировании сборки и вам действительно достаточно выполнить одну команду в терминале и можно сразу начать работу. Последний релиз версии 5.0, добавил нам возможность использовать Tailwind без изменения конфигурации, которая кстати говоря была возможна только с использованием сторонних библиотек (пр. Craco)

React

Ну а теперь давайте пройдемся по текущей ситуации с экосистемой Реакта.

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

Грядущая 18ая версия реакта привнесет полезное обновление для работы хуков — автоматический батчинг всех вызовов сеттера useState, что позволит избежать лишних рендеров:

const [count, setCount] = useState(0); const [flag, setFlag] = useState(false);  function handleClick() {   fetchSomething().then(() => {     setCount(c => c + 1);     setFlag(f => !f);     // React перерисует компонент только один раз   }); } 

React фреймворки

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

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

NextJS / Gatsby

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

NextJS в конце 2021 года получил обновление до 12 версии. В ней команда разработчиков как и прежде сконцентрирована на оптимизации скорости работы приложения. Были представлены Middleware для страниц, позволяющие выполнять действия с запросом в момент его исполнения, что дает возможность авторизовывать пользователя и делать редиректы, еще до выполнения логики страницы. Также NextJS получил Rust compiler (SWC), который в разы увеличивает скорость сборки бандлов приложения.

Gatsby обновился до 4 версии и привнес улучшенное решение статической генерации сайтов, которая не требует пререндера в момент сборки проекта.

Remix

Но самым важным событием конца 2021, в нише фреймворков, стал open source релиз проекта под названием Remix. Это SSR фреймворк, который обладает функционалом в виде вложенных роутов, что дает возможность загружать контент страницы параллельно, а также и обрабатывать ошибки на каждый роут. Еще одним интересным подходом является работа с формами, которая реализована как в старые времена через браузерный API форм, это позволяет реализовывать простые страницы с формами, которые могут работать вообще JS на стороне браузера.

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

React библиотеки

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

Роутинг

В нише SPA приложений лидером был и остается react-router. Он удобен, прост в освоении и предоставляет хуки на все необходимые случаи.

С последним мажорным обновлением react-router предложил нам кардинально новый подход к организации роутов, который также был интегрирован в Remix. Более подробно можно ознакомиться на главной странице проекта reactrouter.com
(Спасибо за комментарий @Amper)

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

Менеджмент состояния

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

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

Стоит заметить, что Redux развивается в сторону решения основных спорных моментов и с релизом Redux Toolkit появилась возможность сократить количество boilerplate кода и мутировать состояние, если кому-то было это важно делать.

Вторым по популярности менеджером состояний является Mobx, за счет простоты использования и реализации реактивности через наблюдаемые объекты (observable).

Формы

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

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

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

  • formik — Еще одна популярная библиотека для работы с формами. Реализована она через компоненты, но также возможно использовать хуки.

Стилизация

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

  • Чистый CSS или препроцессоры (SCSS, LESS)

  • Tailwind

  • styled-components

  • UI библиотеки

    • Material UI

    • Ant Design

    • React-Bootstrap

Запрос данных с сервера

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

  • fetch / axios — для работы с REST API

  • Apollo GraphQL

  • swr, react-query — библиотеки, которые по мимо работы с запросами предоставляют возможность кеширования запросов с ревалидацией, показа состояния загрузки и обработку ошибок.

Предлагаю поделиться своим видением текущей экосистемы реакта. Буду рад прочесть другие мнения в комментариях. Всем удачи и не болейте! 👋


ссылка на оригинал статьи https://habr.com/ru/post/648887/

Ремонт мотора WeDo 2.0

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

Ситуация, при которой детки переламывают кабель моторов Lego WeDo 2.0, достаточно распространена. С переломанным кабелем моторы либо «глючат» (и надо найти правильное положение, в котором они работают) , либо вообще перестают вращаться.

Что делать? Покупать новый мотор? В наших реалиях — это дорого. Даже китайский аналог стоит порядка 15 единиц валюты.

Самое очевидное решение — попробовать отремотировать.

Так случилось, что у меня как раз надломился кабель рядом с основанием мотора. В этом случае — ремонт достаточно прост — достаточно перепаять кабели.

Итак, приступим.

ШАГ 1 — откручиваем винт

Фото мотора снизу
Фото мотора снизу
Открутили винт
Открутили винт

ШАГ 2 — снимаем кожух

Надо сказать, что по сравнению с WeDo 1.0 кожух на удивление легко снимается. На этот раз не нужно «подковыривать» защёлки — достаточно аккуратно подцепить очень тонкой отвёрткой в нескольких местах, постепенно ведя к защёлкам

Вставляем отвёртку и поддеваем крышку
Вставляем отвёртку и поддеваем крышку

Поддеваем кожух с одной стороны и немного отодвигаем:

Отодвигаем, но не снимаем полностью
Отодвигаем, но не снимаем полностью

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

Переворачиваем

Точно также с другой стороны - начинаем с края и ведём к защёлке
Точно также с другой стороны — начинаем с края и ведём к защёлке

Также поддеваем с другой стороны, направляясь к защёлке.

Теперь можно снимать до конца — он действительно хорошо снимается.

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

ШАГ 3 — снимаем планетарный редуктор и вынимаем мотор

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

Сняли кожух
Сняли кожух
Сняли планетарный редуктор
Сняли планетарный редуктор
Вытащили мотор
Вытащили мотор

ШАГ 4 — Отпаиваем контакты

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

Поэтому — пинцетом придерживаем кабель за изоляцию, а не за металл.

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

Отпаяли
Отпаяли

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

Я без сто грамм с первого раза не разобрался, и закрутил их неправильно.

Запоминаем как были закручены кабели
Запоминаем как были закручены кабели

ШАГ 5 — режем и вставляем

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

Затем делаем надрез по середине целого куска кабеля.

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

Делаем надрез по длине отрезанного куска
Делаем надрез по длине отрезанного куска

Теперь вставляем их в крепление. Вставлять нужно до конца места разреза.

Зачищаем концы кабелей, отгибаем металл друг от друга, чтобы получились «Куриные лапки»

Куриные лапки
Куриные лапки

Залужаем и наносим немного припоя.

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

Залудили куриные лапки
Залудили куриные лапки

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

Как можно заметить, пайка у меня не очень профессиональная — но мотор работает хорошо.

Флюс не наносил.

После припаивания каждой тройки проходитесь по всем припаянным контактам тестером на предмет наличия КЗ.

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

Если остались вопросы — жду вас в комментариях.

P.S. Если у меня сломается ещё один мотор, постараюсь снять видео.


ссылка на оригинал статьи https://habr.com/ru/post/648889/

Цифровая музыка и виртуальные исполнители: история музыкального искусства от первых ЭВМ до нейросетей

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

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

Первые музыкальные композиции

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

Принцип работы не был чрезмерно сложным. ЭВИ генерировало в случайном порядке простейшие элементы музыкальной композиции. Заданы они были числами в диапазоне от 0 до 15.

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

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

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

Новые успехи

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

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

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

Ниже — пример композиции в стиле Баха, которую и написала новая программа.

Новое время

Ну и уже с 2010-х начинается настоящий бум «музыкальных технологий». Примерно 6 лет назад один их представителей мира музыки, британский композитор по имени Эшем Куша, создал образ, который впоследствии получил собственное имя — Yona. Это была цифровая певица, чья внешность, «личность» и музыка были написаны компьютерным интеллектом.

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

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

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

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

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

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

К слову, бояться того, что компьютер заменит человека в музыке не стоит — скорее, это будут либо какие-то смешанные коллективы «реальные артисты + ПК», либо чисто цифровые артисты, которые получают какую-то аудиторию, не конкурируя с реальными группами. В конце концов, существует же Мику Хацунэ, которая поет голосом, который создан путем семплирования голоса живой певицы с использованием программы Vocaloid компании Yamaha Corporation.


ссылка на оригинал статьи https://habr.com/ru/company/neuronet/blog/648895/