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

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

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

Часть 1: Основы CI/CD – что это и зачем нужно; обзор GitHub Actions и GitLab CI

В последние годы вы, вероятно, слышали слова "DevOps", "CI", "CD", возможно, даже "GitHub Actions" или "GitLab CI". Но что это всё значит на практике? Нужно ли быть сеньором DevOps-инженером, чтобы с этим разобраться?

В данной статье представлен авторский подход к унификации и централизации механизма обработки ошибок в HTTP-обработчиках веб-сервисов, разработанных на языке Go. Статья подробно рассматривает ограничения традиционных методов обработки ошибок, ведущие к дублированию кода и снижению поддерживаемости. Предлагается новый архитектурный паттерн, включающий использование специализированной сигнатуры функций-обработчиков, кастомного типа ошибки HTTPError для инкапсуляции статуса ответа, сообщения для клиента и внутренней ошибки для логирования, а также Middleware-адаптера для интеграции с фреймворками net/http и Gin. Данный подход демонстрирует повышение читаемости кода, упрощение отладки и обеспечение консистентности ответов API, что представляет собой значимый вклад в практику разработки бэкенд-сервисов на Go.

Привет, Хабрчане! Это Леша Жиряков, техлид backend-команды витрины KION. В прошлый раз я писал о секретах популярности Python, а сегодня будет пост о разработке на React. Расскажу, какие библиотеки стоит добавить в свой набор в 2025 году, приведу плюсы и минусы каждой, данные с GitHub и примеры использования. Начнем!

Всем привет.

Немного контекста. У нас есть легаси проект, который пишется уже на протяжении порядка пяти лет. Когда мы его стартовали, было принято решение использовать redux в качестве стэйт менеджера. Сейчас не вижу смысла рассуждать на тему того, было ли это решение правильным, имеем то, что имеем, а именно кучу кода, мигрировать который на что-то иное вряд ли получится за адекватное время одновременно с написанием новых фич. А в чем проблема, спросите вы, redux прекрасный инструмент, зачем от него отказываться? Проблема в том, что философия глобальности redux побудила команду писать код, который постепенно превратился в неподдерживаемое нечто. Вообще, конечно, странная штука – глобальные переменные испокон веков считались антипаттерном, но redux, который по сути является глобальным объектом, обрел такую популярность и повсеместное использование.  Но это так, мысли вслух.

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

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

❯ Механизм согласования

В моих предыдущих статьях (1, 2) я подробно рассматривал, как работает React.memo, а также делился более эффективными подходами к оптимизации производительности с помощью компоновки. Однако для глубокого понимания работы React необходимо разобраться в основном механизме, лежащем в основе всех этих оптимизаций – алгоритме согласования (reconciliation).

Согласование – это процесс, в результате которого React приводит DOM в соответствие с деревом компонентов. Именно этот механизм позволяет реализовать декларативный подход к программированию на React: вы формулируете свои намерения, а React самостоятельно определяет, как выполнить эти намерения наилучшим образом и с наименьшими затратами.

Когда проект разрастается до десятков экранов, а папка helpers начинает весить больше, чем хотелось бы, приходит время пересмотреть подход к архитектуре. В этой статье — как я пришёл к принятию Feature-Sliced Design на React. Только личный опыт, ошибки и выводы.

До недавнего времени программный доступ к куки в браузере осуществлялся через API document.cookie — простой строковый геттер/сеттер. Для получения одного файла куки приходилось разбирать всю строку вручную и преобразовывать ее в удобный формат. А чтобы записать куки, нужно было сначала сформировать структурированные данные, затем сериализовать их в строку и только после этого присвоить значение document.cookie. Разработчики часто используют популярные библиотеки, например js-cookie, которые делают работу с куки гораздо удобнее.

Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.

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

Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.

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

На одном из проектов мне нужно было реализовать Telegram-бота с использованием Web App. Я выбрал стек: Vite + React + Zustand + TypeScript. До этого я в основном работал с Webpack, и столкнулся с вопросом — как удобно организовать алиасы. В Vite есть resolve.alias, и это удобно. Но дополнительно нужно прописывать пути в tsconfig.json, чтобы IDE понимала, что происходит. А ещё это не работает с HTML-импортами.

💡 Здесь важно: HTML теперь может импортировать модули напрямую, и если бы алиасы работали и там — можно было бы писать одни и те же пути и в скриптах, и в коде, и в конфиге.

Prometheus прекрасно подходит для краткосрочного мониторинга, но у этого решения есть свои ограничения по масштабу, и если вы столкнулись с высоким потреблением памяти/CPU, снижением скорости запросов или вам требуются уникальные лейблы вида user ID, то стоит подумать над внедрением альтернатив. На наш взгляд следующими после Prometheus в линейке стоят Thanos, Cortex, Mimir или VictoriaMetrics. Объективное, насколько это возможно, сравнение характеристик этих решений мы и проведем ниже.

СОДЕРЖАНИЕ

• 3.1. Что важнее: простота или масштаб?
• 3.2. Стоимость
• 3.3. Надёжность и высокая доступность
• 3.4. Насколько подходит по задачам?

• 6.1. Параллельный запуск и проверка
• 6.2. Мониторинг очередей remote_write
• 6.3. Аккуратное отключение Prometheus
• 6.4. Резервное копирование
• 6.5. Тестирование

• 10.1 Используйте recording rules для тяжёлых агрегаций
• 10.2 Не злоупотребляйте лейблами с высокой кардинальностью
• 10.3 Downsample старые точки данных
• 10.4 Осторожно с федерацией Prometheus

Стыдно признаться, я практикую Swarm в 2025 году. Его легко объяснять, быстро готовить и просто использовать. Это инструмент старта в мир контейнеров, когда большой Kubernetes избыточен. Но путь развития Docker оказался не самым прямым. Со временем стало не хватать минимального динамического прокси для Swarm. Такого, который можно запустить один раз, чтобы он сам настраивал маршрутизацию трафика к микросервисам - и забыть. Так появился Millau - ingress-прокси и балансировщик на лейблах. Сейчас он обслуживает собственный сайт и ещё несколько проектов.

Привет, Хабр!

Сегодня рассмотрим одну из самых сильных сторон Symfony — компонент EventDispatcher.

Если очень кратко, EventDispatcher позволяет создавать реактивную архитектуру: одни части приложения инициируют события, другие на них реагируют, не зная напрямую друг о друге.

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

Давно уже было желание сделать что-то простое и полезное в Telegram, но чтобы не пришлось постоянно за этим следить. И вот пришла гениальная идея: чтобы быть всегда замотивированным, можно написать бота, который будет (с какой то периодичностью) сам отправлять мотивационные цитаты в канал?

Этот бот берёт случайные цитаты известных людей из интернета, переводит их на русский язык и отправляет в Telegram-канал по расписанию. Например, утром, днём, вечером и ночью. Звучит просто, правда? Но внутри этого проекта есть всё, что нужно для обучения: чистая архитектура, работа с API, планировщик задач и даже деплой на облачную платформу Railway.

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

Что в итоге получилось и код проекта можно найти по этим ссылкам.

Telegram-канал который получился

Проект на GitHub

Все мы уже много раз слышали и видели заветные I use arch btw и конечно виноваты не те, кто так говорит, ведь это прописано в лицензионном соглашении в процессе установки через очень приятный и понятный даже вашей бабушке GUI. Вам не нужно вручную подключаться к вашему wifi, не нужно размечать и монтировать диски. А установку всех нужных именно вам пакетов за вас сделает сама система, нужно только подписать соглашение ...

Как же пользоваться Hyrpland и стоит ли делать свой Rice?

Nelm — это свободная Open Source CLI-утилита для управления Helm-чартами и их развёртыванием в Kubernetes. Взяв за основу кодовую базу Helm 3, Nelm не только делает почти всё то, что может делать Helm, но делает это лучше, а также предлагает дополнительную функциональность. 

Nelm обратно совместим с Helm-чартами и Helm-релизами, что сильно упрощает процесс миграции для пользователей Helm. Если вы уже работали с werf, то Nelm — это werf, но без гитерминизма, сборки, доставки и очистки образов.

Под катом вас ждут подробности о преимуществах Nelm по сравнению с Helm 3.

Фото важных семейных событий и видео из путешествий, копии важных документов, музыка, фильмы, которых не найти на стримингах — многие задумывались, как сохранить все самое важное так, чтобы ситуация с не вовремя сломавшейся флешкой не обернулась потерей ценных данных навсегда. Кому-то для спокойствия достаточно Google Drive или Яндекс.Диска, но я решил пойти чуть дальше и построить собственное домашнее облако с приложениями Immich и Nextcloud.

Кстати, привет, Хабр! Я Денис Петухов, Python-разработчик в Cloud.ru и сегодня я расскажу, как построил облако в шкафу. По ходу дела дам практические рекомендации по архитектуре, выбору оборудования, приложений, настройке сети и даже приведу расчеты того, что выгоднее, и сколько электричества «съедает» домашняя хранилка в месяц.

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

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

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