Open source *

За время, прошедшее с момента предыдущего стабильного релиза Deckhouse, наша Kubernetes-платформа успела получить сертификацию CNCF для версий Kubernetes v1.22 и v1.23, появилась в списках adopters у Prometheus Operator, а еще — в числе пользователей Cilium. Как раз с Cilium связано главное улучшение в новом стабильном релизе платформы.

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

Команда Rust рада сообщить о новой версии языка — 1.62.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.62.0 вам достаточно выполнить команду:

rustup update stable

Если у вас ещё нет rustup, то можете установить его со страницы на нашем веб-сайте, а также ознакомиться с подробным описанием выпуска 1.62.0 на GitHub.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать beta (rustup default beta) или nightly (rustup default nightly) канал. Пожалуйста, сообщайте обо всех встреченных вами ошибках.

О проекте SObjectizer-5 мы рассказываем на Хабре уже давно и более-менее регулярно. А вот о сопутствующем ему проекте so5extra речь заходит гораздо реже и вскользь. Между тем so5extra развивается уже пять лет (как же быстро летит время) и на днях мы зафиксировали очередную версию. Что представляется хорошим поводом представить вашему вниманию обзор библиотеки so5extra, с акцентом на разнообразие реализованных в ней типов почтовых ящиков (mbox-ов в нашей терминологии).

В этой статье я расскажу, как мы командой пилили пет-проджект в рамках курса ODS по MLOps. Покажу не только финальный результат, но и немного расскажу про процесс работы, какие были сложности, как организовывали эффективную работу в команде. Может оказаться полезным для тех, кто хочет окунуться в Machine Learning и сделать свой пет-проджект, но пока чего-то не хватало. Также будет полезно тем, кто уже работает в области Data Science, но пока не окунулся в атмосферу DS, нет крутых коллег и разгвооров про фреймворки у кофемашины, а опыт командной работы именно в области DS получить хочется.

Сразу про то, что получилось на выходе: https://cryptobarometer.org/

Всем привет!

Уже который год идёт, а мы все ещё пишем читалку со словарями под Android. Настало время для очередной статьи о том, что у нас появилось нового.

▍ Введение

В наиболее популярном случае иметь множество инсталляций GitLab — это антипаттерн. Однако обстоятельства бывают разными: специализация нашего бизнеса привела к тому, что мы администрируем десятки self-hosted GitLab-инстансов обслуживаемых клиентов. Периодически у нас возникает потребность проделать какие-то действия на всех GitLab’ах сразу, чтобы не тратить время на многократное повторение рутинных операций. Все началось с необходимости мониторинга за критическими обновлениями для GitLab. Но аппетиты росли: со временем нам уже хотелось искать по содержимому файлов во всех инсталляциях или даже создавать пользователей.

Расскажем о том, как мы решили эти задачи в рамках внутренней разработки, которую теперь публикуем как Open Source-проект под названием glaball.

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

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

Календари это давнее моё увлечение.

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

Календари обычно требовались для планирования сельхоз работ и проведения религиозных обрядов.

Календари основывались на каких-то природных периодических процессах. Лунный календарь имел в основе изменение вида Луны на небосводе. Солнечный календарь опирался на период обращения Земли вокруг Солнца – год. Год делили на промежутки в виде периода от новолуния до новолуния – месяц. Месяц делили на недели, а недели на дни. Получался лунно-солнечный календарь.

У шумеров недели не было. Месяц делили на дни.

У Майя в неделе было в одном календаре 13 дней, а месяцев в году восемнадцать. Это бытовой календарь. Был у Майя также религиозный календарь содержавший 260 дней, 20 месяцев и 13 дневных недель содержащих по 13 дней.

Не буду утомлять примерами календарей прошлого.

Постепенно официальным календарём в мире стал григорианский календарь, который всем хорошо известен. В этом календаре 365 – 366 дней, 12 месяцев, семидневная неделя. В России остался в употреблении и юлианский календарь (старый стиль), который применяется в церкви.

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

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

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

Привет! Меня зовут Григорий, я техлид в Cloud Infrastructure Team в Сравни. Моя команда отвечает за observability системы и облачную инфраструктуру. Не так давно мы полностью обновили наш стек мониторинга. Хочу рассказать, как у нас организовано хранение long-term метрик без использования Object Storage.

Мы в Сравни долгое время использовали связку Prometheus + Thanos для мониторинга и хранения данных. Для Thanos мы использовали схему с sidecar’ом. Эта схема работала довольно неплохо, но с ростом проекта — росло и потребление ресурсов. Со временем задачи по scrape samples уже потребляли значительные ресурсы. Когда только на Prometheus стало уходить больше 30 ядер vCPU и 100 гигабайт RAM, мы начали искать способы оптимизации потребления ресурсов. 

Первым делом определили требования, которые необходимы для системы мониторинга:
- должно поддерживаться развертывание в Kubernetes;
- система должна быть способна переезжать из одного Kubernetes-кластера в другой без потери данных;
- нужна поддержка downsampling;
- возможность построить high availability систему;
- в идеале, чтобы система требовала очень мало внимания на обслуживание ;)

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

В продолжение наших статей про Chaos Engineering расскажу про недавний опыт проверки на прочность приложений в кластере Kubernetes с помощью Open Source-оператора Chaos Mesh.

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

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

Привет! Меня зовут Сергей, я старший разработчик в Ozon и раньше вообще не был замечен в QA.

Все мы привыкли к лёгкому написанию тестов на Python и Java — это основные языки автотестировщиков с богатым инструментарием утилит и всего, что упрощает жизнь. Что нужно для написания автотестов для HTTP-сервиса на Python или Java? Гугл, бутылочка крафта и два часа времени. 

А как быть в случае с Go? Как раз на нём мы в большинстве случаев пишем микросервисы. И если тесты написаны на другом языке, разработчики не могут внести в них свой вклад или отревьюить их. Поэтому внутри Ozon активно развивается Go-сообщество QA, и этим ребятам тоже нужно тестировать HTTP-сервисы и проверять отчёты в Allure. Как настоящие сварщики мы подумали: «Если чего-то не хватает, нужно написать своё». Сказано — сделано: встречайте опенсорс-библиотеку CUTE в BDD-стиле, которая облегчает тяготы создания автотестов и упрощает переход на Go. Главные фичи: создание HTTP-тестов, возможность реализовывать проверки из коробки, Allure-отчёты и низкий порог входа. Инструкция — под катом.

В 2022 году в сообществе Gamedev.js прозвучал призыв делиться исходниками игр на GitHub. Подборку игр с открытым кодом представляем к старту курса по Fullstack-разработке на Python. Автор этого материала — основатель Enclave Games и конкурса js13kGames.

Привет Хабр!

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

Интерактивное дерево комиксов с связями и обложками, написанное на d3.js 6.
Данные берутся динамически по API Marvel.

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