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

Почему скрипты?

• Гибкость: кастомизация проверки под свои нужды
• Простота: запуск в cron или systemd - и можно с чистой душой забыть о проблеме
• Самовосстановление: скрипт может не только найти проблему, но и исправить её (рестарт службы, чистка ненужных файлов, логов)

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

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

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

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

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

Давайте разбираться. Без булшита и розовых очков.

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

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

Собеседование по System Design — это не просто проверка технических знаний, а настоящее испытание вашего инженерного мышления. В отличие от алгоритмических задач, где есть чёткие правильные и неправильные ответы, здесь всё строится на умении анализировать, взвешивать компромиссы и предвидеть проблемы до их появления. Ирония в том, что даже опытные разработчики часто проваливают эти собеседования, потому что сосредотачиваются не на том. Они могут идеально знать, как работает Kafka или Cassandra, но если не умеют структурировать свои мысли и задавать правильные вопросы, их шансы резко падают.

После выхода первой статьи про svg-виджеты для tcl/tk прошло более года. За это время вышел не только tcl/tk версии 9.0, но и сам пэт-проект возмужал и продолжает взрослеть. Напомним, что проект svgwidgets, примеры и интерпретаторы tcl/tk с необходимыми пакетами для работы с svg-виджетами можно найти на github-е.
В проекте svgwidgets на github-е можно найти версию интерпретатора tclexecomp как для linux64 (папка tclexexcomp902), собранного из исходников tcl/tk-9.0.2, так и версию интерпретатора на базе tcl/tk-8.6 для платформ Linux64 и Win64 (папка tclexecomp200).
К ранее созданному на github-е подкаталогу examples/CryptoArmPKCS_Test, в котором выложен исходный код криптографической утилиты для работы с электронной подписью cryptoarmpkcs, который предназначен для запуска на платформе Linux64 в среде tcl/tk-9, добавлены аналогичные папки для запуска утилиты cryptoarmpkcs в среде tcl/tk-8.6 на платформах Linux64 (папка examples/CryptoArmPKCS_Test_Tk86) и Win64 (папка examples/CryptoArmPKCS_Test_Tk86_Win64). Для запуска этой утилиты ничего дополнительного устанавливать на свой компьютер не требуется. Достаточно выбрать соответствующий интерпретатор из папки tclexecomp200 или tclexexcomp902 и выполнить файл mainguipkcs_svg.tcl из соответствующей папки ~/examples/CryptoArmPKCS_Test, например:

C:>C:\Temp\tclexecomp64_v200_svg_Win64.exe c:\Temp\CryptoArmPKCS7_Test_Tk86_Win64\mainguipkcs_svg.tcl

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

Данная статья является четвёртой частью перевода руководства по повышению производительности Firebird за авторством А.Ковязина и Э.Грегорио от 23.05.2024 (и потому продолжается сквозная нумерация пунктов), а так же текстовой расшифровкой соответствующего видео.

Привет друзья, сегодня с Вами мы соберём трёхканальный вольтамперметр на базе ESP32-S3. Многие из Вас, уже долгое время ждали этот проект, поэтому при его сборке я учёл все Ваши замечания в комментариях под видео к вольтамперметру на Arduino, вольтамперметру на ESP8266 и сделал проект максимально простым, я избавился от большого количества пайки, новый вольтамперметр буквально можно спаять навесным монтажом, так как он состоит всего из 5 модулей. Так же избавился от ненужных компонентов, навроде датчика температуры, блока управления вентиляторами, так как модули, на основе которых мы будем с Вами собирать лабораторный блок питания уже имеют и датчики температуры, и могут управлять скоростями вентилятора, поэтому данные компоненты в новом вольтамперметре я упразднил.

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

Индекс — это как указатель в толстенном справочнике. Без него, чтобы найти нужный термин, вы обречены листать страницу за страницей. С ним — вы мгновенно открываете нужный раздел. Но что, если указатель сам размером с полкниги? Или ведет не туда? Такой помощник только вредит. С индексами в БД всё то же самое. Грамотная стратегия индексирования — это полет. Ошибочная — это бег в мешках по болоту.

Всем привет! Сегодня хочу углубиться в одну из самых важных тем в мире Zephyr OS — синхронизацию потоков и задач. Если вы хоть раз работали с k_thread_create, гоняли потоки туда-сюда и ловили bus fault, вы меня понимаете.

Когда задача одна — всё просто. Но как только вырастает многопоточность, задачи начинают драться за общий ресурс — и тут без надёжной синхронизации не обойтись. У Zephyr OS есть три главных инструмента для этого: spinlock, mutex и semaphore. Каждый со своим характером и подводными камнями.

Описание попытки создания компилятора для Intel-8008, который вызывается через консоль, на языке программирования C, используя динамические библиотеки и полиномиальное хеширование

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

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

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

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

Сегодня хочу рассказать вам о библиотеке yolo_detector — простой, удобной и производительной обёртке для использования моделей компьютерного зрения YOLO на языке Rust.

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

Звёздный пролёт [stellar flyby] – это событие, при котором другая звезда проходит достаточно близко к нашей Солнечной системе, чтобы вызвать в ней заметные изменения. Наш район в Млечном Пути относительно малонаселён, поэтому звёздные пролёты происходят реже, чем в других частях галактики. Но они всё же происходят.

Десятки тысяч компаний используют Ansible для управления конфигурациями и автоматизации ИТ-процессов. И мы подготовили подборку материалов, которые помогут познакомиться с этим инструментом — от базовых руководств уровня «с чего начать» до продвинутых практик по написанию эффективных плейбуков.

Этой проблеме я уже посвятил две статьи. Ну, как проблеме — проблеме для меня. Никак не удавалось охватить её целиком, когнитивно и ментально промоделировать. Появление Copilot кардинально всё изменило — ментальные границы раздвинулись, и здесь я выкладываю окончательное решение для семейств микроконтроллеров Synergy и RA8 от Renesas.

Алгоритм Берлекэмпа-Месси используется для поиска минимального многочлена ЛРП. Его внешний вид может быть слегка пугающим, особенно если без должной подготовки нарваться на доказательства его корректности. Мы же здесь просто посмотрим работу данного алгоритма на конкретном примере и произведём проверку с помощью средств линейной алгебры.

Несмотря на развитие лингвистических моделей, я подумал, что моя версия супервизора может быть достаточно интересна для размещения в статье. Назначение супервизора - поднять повторно программу, которая по каким-то причинам упала с ошибкой. Причём если программа завершила работу без ошибки, то она перезапущена не будет, как и не будут создаваться логи. В логах пишется время падения и тип ошибки. Универсальный Makefile может быть интересен тем, что его достаточно закинуть в папку с исходниками, добавить необходимые пути вида:
LDFLAGS = -I/usr/include/boost
LIBS = -lboost_serialization