Open source *

Зимняя школа RISC-V — совместный проект YADRO и ведущих технических вузов России и Беларуси. В этом году зимняя школа прошла во второй раз: 12 лекций по разработке на RISC-V в январе и проектная работа с защитой в начале февраля. Далее в статье мы расскажем об итогах школы, дадим слово кураторам и начнем делиться самыми интересными проектами потока.

Для проектов мы предложили 19 тем, которые распределили по пяти вузам — СПбГУ, ИТМО (Санкт-Петербург), ННГУ (Нижний Новгород), НГУ (Новосибирск) и БГУИР (Минск). В итоге своих героев не нашла только одна тема: почти 100 студентов защитили 18 проектов. Забегая вперед, скажем: два проекта мы осветим в этой статье, а некоторые другие — в отдельных.

Привет! Меня зовут Иван, и я автор проекта «Код на салфетке» — небольшой команды, в которой мы совмещаем написание обучающих статей, коммерческую разработку и open source.

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

Один из принципов нулевого доверия гласит: никогда не доверяй, всегда проверяй (Never trust, always verify). В этой статье мы рассмотрим, как реализовать соблюдение такого принципа в системе аутентификации на примере продуктов с открытым исходным кодом OpenAM и OpenIG.

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

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

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

TLDR: Исходный код...

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

Моя первая реакция: «Ну вот, опять…» (цензура соблюдена). Представьте: десятки задач, а к каждой — скриншоты редактора с кодом, подписи в формате «Рисунок 1.2 — Реализация сортировки кучей», выравнивание по шаблону, бесконечные правки форматирования. На один такой отчет уходило до двух часов. После месяца мучений я понял: так дело не пойдет. Так и родился мой спасительный проект — «Отчет Creator».

Продолжаем реализацию концепции Сотрудник-Трудоустройство-Назначение на должность в IDM Midpoint. У нас на стороне Админа все выстроилось все назначается, теперь надо это реализовать со стороны пользователей! Даже если вы думаете что напишите свою GUI тут надо в первую очередь решить проблемы с авторизацией для просмотра для действий для этого подойдёт и встроенное GUI - в данный момент(4.9.1) частично не работает частично невозможно получается - кое что пришлось переделать по сравнению с частью 1,2 этого повествования.

Окончательная схема работающей концепции Сотрудник-Трудоустройство-Назначение на должность в IDM Midpoint 4.9.1

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

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

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

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

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

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

И так как недавно я получил статус Kaspersky Certified Systems Engineer - пришло время рассмотреть на практике один из простых примеров расширения возможностей мониторинга безопасности управляемых серверов.

Demo | GitHub

Особенности Fast Data Grid:
— Невероятно быстрый
— Многопоточный
— Всего 523 строчки кода
— Нет зависимостей
— Vanilla JavaScript

Попробуйте скролл и поиск по 1 000 000 строк — Fast Data Grid.

В статье расскажу про работу с потоками.

Привет, Хабр! Меня зовут Андрей Гетманов, я работаю ML-инженером в Исследовательском центре “Сильный ИИ в промышленности” в ИТМО, а кроме того являюсь энтузиастом open source. В этой статье хочу рассказать о нашей новой разработке ― ИИ-инструменте, который помогает репозиторию стать лучшей версией себя.

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

В современном мире невозможно себе представить взрослое приложение, которое не экспортирует телеметрию. Метрики — важнейший атрибут поддерживаемого софта; для всех более-менее профессиональных технических специалистов термин «visibility» давно вытеснил прочие остальные баззворды наподобие «test coverage» и «continious integration».

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

Отсюда вырос знаменитый «слоган» эрланга «Let It Crash!», высмеиваемый и всегда неверно трактуемый теми, кто неутомимо отслеживает все исключительные ситуации… и спотыкается об отсутствие нужного для их корректной обработки контекста в месте ловли. «Let It Crash» — означает не «Хрен с ними, с ошибками», а «Случилась какая-то ерунда в рантайме, но мы к ней готовы».

¡NB! В тексте нет прямых примеров использования телеметрии в ООП/ФП проектах, но я глубоко убежден, что этот текст будет полезно прочитать, даже если вы просто перекладываете джейсоны из пустого в порожнее на шарпах, котлине или хаскеле.

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

Цель этой статьи — **не** создавать очередной туториал по сборке чат-бота с OpenAI. Таких материалов уже достаточно.

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

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

---

## Зачем?

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

Такой ассистент может использоваться в разных сценариях:

- **Быстрые ответы на частые вопросы**

- **Поиск по документации как в Algolia**

- **Помощь пользователям в навигации по документации**

- **Анализ пользовательских вопросов и хранение их для анализа**

---

## Краткое содержание

Ниже приведены три основные части решения:

1. Чтение файлов документации

2. Индексация документации (разбиение, перекрытие, эмбеддинги)

3. Поиск по документации и интеграция с чат-ботом

---

## 1. Чтение файлов документации

Вместо того чтобы жестко прописывать текст, вы можете просканировать папку и найти все `.md` файлы с помощью `glob`.

От пет-проекта в продукт: мой гайд по превращению GitHub-репозитория в востребованное решение. Разбираем запуск для русскоязычных проектов на Product Radar — разбором ошибок, которые убивают трафик, и тактиками для первых платящих пользователей.

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

Статья написана по мотивам выступления Максима Чудновского, лидера по продукту Platform V Synapse Service Mesh СберТех на Highload++, где он рассматривал кейс миграции с OpenShift на Platform V DropApp, но предложенные подходы могут быть использованы и для миграции на другие российские Kubernetes-платформы: Deckhouse, Штурвал, Боцман и так далее.

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

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

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

Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и всем советуем. Обо что споткнулись и всем советуем там не спотыкаться.

Хочу показать три приёма, как можно ускорить загрузку интерфейсов с Backend-Driven UI и улучшить UX. Решения показали хорошие результаты на демо-версии, но увы, пока ещё не внедрены в реальный проект. Было бы интересно обсудить с вами, как эти приёмы могут помочь в боевых задачах и что ещё можно улучшить.

Пришло, пришло время (экспертов по опенсорсу) моей истории опенсорс-проекта. Было столько всего, что до технических деталей (почти) не дойдёт – они есть и в более древних свитках статьях.

Началось всё в 2010 году. Я только закончил аспирантуру и попал в новый для меня проект в Интеле фулл-тайм разработчиком. Мне нужно было внедрить автоматическое тестирование десктопных GUI приложений для внутреннего пользования. Опыт подобный уже был накоплен с середины 2006-го тоже в Интеле, но подходящий инструмент надо было еще найти или даже создать. Получилось что-то среднее: найти и воскресить!