Готовили релиз нашего нового решения для 1С по отправке СМС-подтверждений и столкнулись с классической задачей. Документацию мы ведем в Markdown. Это удобно для нас, но не для конечного клиента.

Клиенту нужен привычный PDF. Простой и надежный.

Главный вопрос: как автоматически собирать несколько .md файлов с картинками в один PDF-файл прямо в пайплайне GitLab CI? Особенно когда твои раннеры работают на PowerShell под Windows, как у нас.

Решение нашлось в связке Docker и Pandoc. Вот пошаговый план

Разработка с помощью AI‑инструментов меняет подход к созданию ПО. Я сам убедился в этом на практике: всего за два дня мне удалось создать Text Extract API для RAG, используя Claude 4.0, Gemini Pro 2.5 и IDE Cursor. Этот эксперимент показал, что нейросети — уже не просто хайп, а мощный ассистент, способный значительно ускорить процесс разработки.

Наша команда занимается созданием ПО для IT‑специалистов — программу Управление IT‑отделом 8. В ней есть блок для работы с заявками от клиентов и обширная база знаний. Возникла идея: интегрировать нейросети для автоматической обработки тикетов. Кейс прост:

Прилетает тикет от клиента > Нейросеть смотрит в базу знаний и готовит ответ > IT‑специалист либо использует ответ нейросети, либо нейросеть отвечает автоматически.

Для реализации такого функционала необходимо обучить AI‑модель на нашей базе знаний, а это требует качественного извлечения текста из различных документов. Эта статья посвящена первому этапу этого процесса — созданию API для извлечения текстовых данных из файлов любых форматов, что критически важно для эффективной работы с Retrieval‑Augmented Generation (RAG).

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

Кому из нас не знакома ситуация, когда «горит» вообще всё и сразу? Кажется, что каждая задача кричит: «Сделай меня первой!» И вот тут‑то и возникает ступор: за что хвататься, с чего начать? Методик приоритизации существует великое множество — от простой и понятной матрицы Эйзенхауэра до запутанных фреймворков вроде WSJF. Но как во всем этом разобраться и не утонуть в бесконечных таблицах и формулах?

Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT‑отделом 8. Я работаю в компании Софтонит. В этой статье я постараюсь простым языком рассказать о самых популярных подходах к приоритизации задач. Мы разберем их плюсы и минусы, посмотрим на реальные примеры и, надеюсь, вы найдете тот инструмент, который будет вам полезным и поможет навести порядок в бэклоге, а также сделать процесс приоритизации четким и понятным.

В Agile есть прекрасная штука, которая называется Daily Standup или «Ежедневный стендап». Короткая ежедневная встреча команды, во время которой каждый сотрудник делится своими достижениями, планами и затруднениями. Эти встречи позволяют держать руку на пульсе и решать возникшие трудности быстро, а так же не терять фокус на текущей работе. Меня зовут Виталий, я хочу рассказать в этой статье о том, с какими проблемами мы столкнулись при внедрении в команде стендапов (хотя казалось бы что‑там сложного) и как их решили. Получилось, на мой взгляд, достаточно просто, красиво и функционально.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

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

Каждый из нас хотя бы раз в жизни задумывался о том, что время неумолимо и быстротечно. Вроде бы вчера ты окончил школу и поступил в университет, а уже сегодня тебе 36 лет, ты женат и у тебя двое детей, а по ощущениям та пропасть времени которая прошла, слилась в один миг. Все очень стремительно…Не так давно, в наше непростое время я был на онлайн-конференции слушателем и один из спикеров (известный предприниматель и основатель крупной ИТ-фирмы с множеством филиалов по всей России) говорил о своем личном и рабочем времени. Все как у всех: времени мало, то что есть трудно распределить между важным и… важным, плюс семья, одно накладывается на другое и в результате нет ни на что времени. Конференция была онлайн, докладчик был дома, выступая в череде таких же докладчиков, доклады которых слились в одним и слушались мною фоном. Но этот харизматичный докладчик как-то по-домашнему все рассказывал, даже показал нам свою собаку-пекинеса (чтобы вы понимали про атмосферу доклада). Столь необычная подача материала естественно приковала к себе мое внимание и я начал внимательно его слушать. Речь была о книге Даниила Гранина "Эта странная жизнь" и методе Любищева, который практиковал автор доклада. Он сказал честно, что эта вторая его попытка использовать этот метод в работе и личной жизни. Он не знает на сколько его самого хватит (я намеренно не рассказываю о сути, т.к. позже постараюсь сделать это сам). Ну и в конце доклада докладчик посоветовал прочесть эту книгу… В результате чтения родился блок учета времени в мобильном приложении.

1. Она не имеет встроенной синхронизации с несколькими компьютерами (точнее сделать то ее можно, через тот же DropBox, но с бубном);
2. Она постоянно висит в панели задач в списке открытых окон;
3. При нажатии на Ctrl+D (свернуть все окна), она сворачивается, как и любое другое окно. Что не очень удобно.