Как стать автором

Всем привет! Меня зовут Артемий Иванов, и это моя первая статья на Хабре. В ней я хочу поделиться опытом, который получил, работая над задачей кастомизации поиска.

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

Разобраться во всех нюансах было непросто — приходилось вникать в обилие терминов и тонкостей «на ходу». В этой статье я покажу, как можно сделать поиск гибче с помощью Spring Data Elasticsearch — и всё это на конкретных примерах из практики.

Здравствуй, дорогой читатель!

Меня зовут Антон, я молодой инженер, который совсем недавно своими тонкими неокрепшими ручонками пробил стенку из кальцита, выбрался в неизведанный мир проводов и индийских драконов да со всего своего юношеского маху сиганул навстречу приключениям.
Мне предстоит узнать много нового и отстроить свое космическое судно… или, может, ноев ковчег? Нет, мне предстоит отстроить свою систему; систему под номером d96. В процессе ее строительства, как подобает всякому капитану, я буду вести бортовой журнал.
Итак, запись #1…

Когда-то я занимался спортивными парными танцами. Часто на тренировках была необходимость узнать темп (или скорость, если немного подушнить насчёт терминов) играющего трека, который измеряется в «ударах в минуту» (beats per minute, bpm)

Спортсмены используют для этого разные сайты/приложения, где нужно пальцем «протапать» ритм. Я и сам таким пользовался, но однажды я задался вопросом — смогу ли я сделать браузерный сервис, который сможет определять bpm из записанного через микрофон аудио

Эта статья как раз о том, как я его сделал

Я не буду вдаваться в тонкости реализации непосредственно UI: у меня уже был на момент начала разработки пет-проект на React, и сервис я решил делать на базе него.

Ты стоишь посреди пустого офиса, за окном апрель 2025 года, дождь стучит по стеклу, а ты смотришь на свой стартап — дитя, в которое вложил годы, деньги и кусок души. Ты уже не тот, кем был, когда начинал. Бизнес — это не просто цифры в Excel и питчи для инвесторов. Это алхимия, которая перекраивает твою личность, как скульптор глину. Иногда ты становишься сильнее, иногда — жёстче, а иногда теряешь то, что казалось вечным. Вот 10 вещей, которые бизнес меняет в тебе навсегда. Это не хорошо и не плохо — это просто правда.

Я пишу о том, как создала fake exploit за 7k $ - фейковая уязвимость, которая не наносит вреда, но выглядит как реальный эксплойт. Это не просто пранк, а образовательный инструмент, позволяющий понять структуру эксплойтов, изучить уязвимости и их демонстрацию. Рассматриваются out-of-bounds write, JIT spray, а также показывается, как можно создавать видимость опасных действий, не причиняя реального ущерба. 

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

В этой статье рассмотрим пример практической реализации RAG (Retrieval-Augmented Generation) на Python для ответов на вопросы пользователей с опорой на нормативную базу технических стандартов. В моём случае это строительные документы: СНиПы, СП, ГОСТы и другие. Готовое решение можно протестировать в строительном Telegram-боте: https://t.me/Pdflyx_bot - данний бот генерирует ответ на основании базы знаний, приводит цитаты и указывает страницы документов, откуда была взята информация.

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

Всем привет! Недавно закончился PGConf, где большая часть докладов была посвящена новым фичам PostgreSQL Pro, и лишь немногие касались ванильной версии. В прометей Лаб я влился с октября 2024 года и начал развивать сервис администрирования баз данных. Сегодня я хочу поделиться нашим подходом к мониторингу, который не требует лицензий, при этом экономит время и нервы.

Если вы DBA, то вы наверняка сталкивались с задачей мониторинга разных инстансов баз данных — PostgreSQL, MSSQL, MariaDB, Oracle или что-то из NoSQL — на разных ОС, от bare metal до PaaS. Настройка мониторинга в таких условиях может занять недели, а ошибки в алертинге приводят к простоям.

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

Я тоже через это проходил, поэтому в Prometey Lab мы сфокусировались на переносимом, масштабируемом, k8s ready решении, на типовых компонентах которое можно оперативно развернуть и с минимальной болью занести в разрешенный техстек. На последней демо, при наличии тех учеток в бд, весь процесс подключения нового клиента к мониторингу занимает 40 минут и поддерживает кастомизацию под любые нужды.

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

Привет.

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

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

Этой статьёй я хочу внести некоторые правки в алгоритм развёртывания, который я описывал год назад вот здесь. Статья тогда получилась объёмная, и я искал способы её сократить, в результате чего опрометчиво пренебрёг несколькими сценариями, которые пригодились мне в дальнейшей разработке. Они образовали техдолг, который мне необходимо закрыть ввиду грядущего продолжения.

Расскажу о признаках неизбежности «перезапуска» проекта и разработки новой версии сайта с «чистого листа». Рассмотрим причины, по которым сайт оказывается в такой запущенной стадии. Найдем позитивные моменты в данной, казалось бы, наглухо негативной истории. Немного углубимся в технику процесса. В конце — чек‑лист для проверки своего проекта!

Всем привет! Меня зовут Виген Мовсисян, я Frontend-разработчик в QIC digital hub. В этой статье я расскажу, как мы внедрили технологию Canvas, какие задачи он помогает решать, что уже успели сделать и какие у нас планы на будущее.

Материал основан на моём докладе с QIC Tech Meetup, полную запись вы можете найти на YouTube.

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

*В текущей версии отсутствует кнопка «Назад» — для возврата в предыдущий раздел воспользуйтесь стандартной кнопкой браузера. 

Итак, начнём погружение в удивительный мир возможностей Canvas.

Читаю статью, вижу буквы, вижу слова, в предложения сложить не могу. О чём статья? Наверное, слишком умно написано? Или наоборот текст ни о чём и написан косноязычным автором? На самом деле возможны оба варианта. Но чаще второе, чего уж там.

В этой статье я хотел бы рассмотреть вышедший буквально на днях стандарт NIST 800–61r3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management» (Рекомендации и соображения по реагированию на инциденты для управления рисками в сфере кибербезопасности). Замененный стандарт 800–61r2, выпущенный в далеком 2012 году, был полностью переработан и текущая версия существенно отличается по структуре и подходу к вопросу реагирования на компьютерные инциденты.

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.

Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.

Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.

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

Ручная проверка модулей контроля питания отнимала 4 часа на устройство. Я собрал стенд на Python, сократив время до 75 минут на 5 устройств. В статье: как превратить неттоп в мозг системы, избежать «фейерверков» из реле и заставить операторов пить кофе вместо того чтобы работать!

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

А так же на практических примерах и наших ошибках поговорим о плюсах гибких методологий управления проектами.

Рассмотрим техники построения и улучшения RAG систем: от нарезания текстов на куски, до продвинутых способов улучшения качества ответа.

Этим блогом можно пользоваться как шпаргалкой для проектирования своего RAG-а и/или для подготовки к собеседованиям.

Все полезные ссылки и материалы, на которые я опирался будут в конце.