База знаний помогает пользователям быстро понять, какие возможности есть у облачных сервисов — так же, как качественный README объясняет назначение open source‑проекта. 

В этом материале мы собрали несколько интересных бесплатных инструментов для подготовки README.

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

GitOps — широко известен и востребован, поэтому по теме регулярно появляются новые материалы для начинающих, а также специализированные инструменты. Мы в Beeline Cloud подобрали примечательные вводные статьи, гайды и open source-решения, которые интересно изучить и потестировать: от управления DNS-зонами и секретами до GitOps-инструментов от энтузиастов и крупных фирм-разработчиков.

Каждый раз, когда речь заходит о новом проекте, начинается вечный спор: какой фреймворк выбрать? Go или Rust для производительности? Python для скорости разработки? А может, стоит попробовать что-то на Elixir? Муки выбора знакомы многим. Вместо того чтобы в очередной раз теоретизировать, я решил пойти другим путем: взять и протестировать их все.

Так родилась идея проекта Framework DevBox — универсальной песочницы, где десять популярных фреймворков на разных языках упакованы в Docker-контейнеры и готовы к запуску одной командой.

Подготовил сборник из 150+ тестовых заданий для продактов и проджектов – забирайте, чтобы повысить свои шансы пройти собесы и трудоустроиться в нужную компанию!

В сборнике найдете тестовые от таких компаний как: Яндекс, Т-Банк, ВК, Авито, Озон, АльфаБанк, МТС, Сбер, AviaSales, SkyEng, 2ГИС, inDrive, HeadHunter, Нетология, Мегафон и многих других.

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

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

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

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

Будут технические детали, теория графов и немного рефлексии.

Команда Python for Devs подготовила перевод статьи о том, как найти самый быстрый способ загрузки данных в PostgreSQL с помощью Python. Автор пошагово сравнил разные методы — от построчных вставок до COPY с потоковой генерацией CSV — и показал, как ускорить процесс более чем в 250 раз при нулевом потреблении памяти.

Привет, Хабр! В предыдущих частях руководства мы разобрали rsync вдоль и поперек - от базового синтаксиса до продвинутых "трюков" для бэкапов и деплоя. Казалось бы, вот он, идеальный инструмент на все случаи жизни. Но как часто бывает в IT, универсальных решений не существует.

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

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

Но откуда она взялась, сама эта музыка? Почему она именно такая и звучит именно так? Как вообще возникла традиция её использовать? Уверен, кто-то где-то уже рассказывал, ибо это база, но повторение — мать учения, а также бальзам для ностальгии. Обмажемся же им поскорее!

В этой части рассмотрим с теоретической стороны разработку дополнений (add-ons) для Home Assistant Operating System.

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

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

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

Первая встреча с Turbo Pascal

Начать стоит с самого начала, когда я впервые увидел Turbo Pascal 5.0. Тогда для меня это было что‑то на грани чуда.

Ведь как в те времена делалось «в норме»:

Представьте: у вас 17 предприятий, на каждом работают сотни операторов, слесарей, аппаратчиков. Каждый должен знать свое оборудование, уметь его обслуживать и — главное — работать безопасно. А еще каждый завод ведет учет по-своему: кто в Excel, кто на бумаге, кто как придумал.

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

Именно с этой задачей к нам в ИТ пришли коллеги из бизнеса. Вопрос звучал не как «сделайте нам новую систему», а как «нам сложно управлять компетенциями в текущем виде, помогите». Это важный момент: мы в СИБУРе не создаем продукты ради самой разработки. Производство приходит к нам с проблемой или потребностью, а ИТ подключается как партнёр, который превращает методологию и практики бизнеса в работающий цифровой сервис.

Так появился проект «Инженерный стандарт» — разработка на стыке бизнеса и ИТ, цель которой была не просто автоматизировать Excel, а выстроить единый, масштабируемый и прозрачный процесс управления компетенциями.

Недавно мы представили MWS Container Platform — платформу для управления приложениями и инфраструктурой на базе Kubernetes. А сегодня в статье предлагаем взглянуть на гайды по теме ИБ при работе с оркестратором: базовые материалы для начинающих, референсы для опытных инженеров и разборы распространенных ошибок. В целом материалам будет полезен системным администраторам, DevOps-инженерам и тем, кто начинает работать с Kubernetes.

Эта статья (точнее, цикл статей) — адаптированный перевод большого исследования “The Prompt Report: A Systematic Survey of Prompt Engineering Techniques” c arxiv.org. Перевод мы выполняли в тандеме с коллегой — Анастасией Тарабакиной. 

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

В первой части мы обсудим основную терминологию промпт-инжиниринга и базовые текстовые техники промптинга: few-shot и zero-shot техники. Далее речь пойдет о техниках Chain-of-Thought, декомпозиции и ансамблировании промптов (часть 2); о мультиязыковых и мультимодальных техниках (часть 3), а также о промптинге для ИИ-агентов (часть 4). В заключение, мы поговорим о том, как снизить риск галлюцинаций и предотвратить промпт-инъекцию (часть 5).

Привет, Хабр! Меня зовут Максим, я главный системный администратор. Сегодня мы поговорим о боли, знакомой каждому, кто работает с мониторингом: об усталости от алертов. О том самом звонке в 3 часа ночи из‑за службы, которая упала и сама же поднялась. О сотне писем «Host down» после падения одного магистрального коммутатора. Это не просто раздражает — это прямой путь к выгоранию команды и пропущенным реальным инцидентам.

«Шумные» алерты — это не особенность Zabbix, а симптом его неправильного использования. По умолчанию Zabbix, как и любой мощный инструмент, требует тонкой настройки. Без нее он превращается в генератор информационного мусора, который обесценивает саму идею мониторинга. Проблема в том, что постоянный поток нерелевантных уведомлений притупляет бдительность. Инженеры начинают игнорировать оповещения, что катастрофически увеличивает время реакции на настоящие сбои (MTTA/MTTR) и, как следствие, время восстановления сервиса (RTO). Это уже не операционная проблема, а прямой бизнес‑риск.

В этой статье мы построим многоуровневую систему защиты от «шума» в Zabbix. Мы пройдем путь от базовых, но критически важных техник, до продвинутых сценариев автоматизации. Мы научим Zabbix отличать кратковременный всплеск от реальной проблемы, понимать топологию вашей сети, коррелировать несвязанные на первый взгляд события и даже предсказывать проблемы до их возникновения. Финалом будет настройка надежного канала оповещений в Telegram и пример автоматического «самолечения» системы. Никакой теории — только практика, конфиги и команды, готовые к внедрению в прод.

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

Так же внезапно (и не так уж безболезненно) интернет получил новую «дорожно-транспортную» логику: QUIC и HTTP/3. В этой статье разберём, что конкретно дают HTTP/3/QUIC веб- и мобильным приложениям, где эффект заметен сразу, а где — только после тщательного теста. Детали под катом.

Сколько часов в день вы проводите в терминале? Часто задумываетесь о том, что какую-то операцию можно сделать быстрее? Любите привлекать внимание коллег необычным видом своего рабочего стола? Сегодня я решил собрать не просто интересные приложения, позволяющие повысить продуктивность работы, но и те, которые однозначно вызовут внимание окружающих и вопросы в стиле «а что это за софтина такая?».

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

Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.

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

Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.