Есть ощущение, что OCR работает ровно до первого реального чека. Пока смотришь демо — всё красиво, как только попадаешь в прод — начинается цирк с буквами и цифрами, которые внезапно меняются местами. И вот ты уже не распознаёшь текст, а разгадываешь квест.
Неделя ушла на борьбу с одной, казалось бы, простой вещью — чеками банкоматов. На бумаге всё выглядит тривиально: есть код ошибки, его надо распознать и сохранить. В реальности OCR спокойно превращает 6 в 0, 5 в S и делает из фиксированного кода какой-то криптографический ребус, который потом нужно как-то интерпретировать.
Кодов ошибок банкоматов оказалось около 20 тысяч, но плюс в том, что они фиксированы. Я просто сложил их все в PostgreSQL и пошёл от обратного: не доверять OCR, а искать ближайшее совпадение. Беру распознанный код и через нечёткий поиск + расстояние Левенштейна нахожу то, что он «хотел сказать».
Нечёткий поиск — это способ находить строки, которые похожи, а не полностью совпадают с запросом (например, с опечатками или разным написанием).
В PostgreSQL он реализуется через метрики сходства
Есть расстояние Левенштейна — это метрика, которая показывает, сколько минимальных операций (вставка, удаление, замена символа) нужно, чтобы превратить одну строку в другую.
Сначала фильтр по similarity, потом сортировка по расстоянию — и на выходе наиболее вероятный вариант.
Фактически этим запросом я закрываю 1–2 ошибки распознавания без отдельной логики. OCR ошибся — база поправила. Никакой магии, просто аккуратно использованные инструменты. Похожий подход, кстати, используется и в FineReader.
Параллельно открыл свой старый проект на NodeJS. Посмотрел код и поймал странное ощущение: вроде бы писал я, но читать больно. Очень быстро становится понятно, как растёшь — по тому, насколько раздражает собственный код из прошлого.
Отдельный цирк был с AI-агентом. Сломалась сборка из-за библиотеки figlet, и «умное» решение оказалось простым: удалить библиотеку и захардкодить ascii-арт. Логика железная. Пришлось руками дожимать до нормального решения и заменить на cfonts. В очередной раз убедился: AI отлично ускоряет, но мусора генерирует не меньше.
В итоге для CLI-интерфейса взял @clack/prompts https://www.npmjs.com/package/@clack/prompts — неожиданно аккуратная библиотека. Минимум лишнего, всё работает как надо.
Чем дальше копаюсь в таких задачах, тем яснее вижу: проблема редко в «сложной технологии». Обычно всё ломается на стыке — OCR, данные, логика. И вот там уже начинается настоящая работа.
Неделя ушла на борьбу с одной, казалось бы, простой вещью — чеками банкоматов. На бумаге всё выглядит тривиально: есть код ошибки, его надо распознать и сохранить. В реальности OCR спокойно превращает 6 в 0, 5 в S и делает из фиксированного кода какой-то криптографический ребус, который потом нужно как-то интерпретировать.
Кодов ошибок банкоматов оказалось около 20 тысяч, но плюс в том, что они фиксированы. Я просто сложил их все в PostgreSQL и пошёл от обратного: не доверять OCR, а искать ближайшее совпадение. Беру распознанный код и через нечёткий поиск + расстояние Левенштейна нахожу то, что он «хотел сказать».
Нечёткий поиск — это способ находить строки, которые похожи, а не полностью совпадают с запросом (например, с опечатками или разным написанием).
В PostgreSQL он реализуется через метрики сходства
similarity и позволяет искать «ближайшие» совпадения вместо точных. Есть расстояние Левенштейна — это метрика, которая показывает, сколько минимальных операций (вставка, удаление, замена символа) нужно, чтобы превратить одну строку в другую.
Сначала фильтр по similarity, потом сортировка по расстоянию — и на выходе наиболее вероятный вариант.
SELECT code, levenshtein(code, '526D6O0') AS dist
FROM atm_error_codes
WHERE similarity(code, '526D6O0') > 0.3
ORDER BY dist ASC
LIMIT 1;
Фактически этим запросом я закрываю 1–2 ошибки распознавания без отдельной логики. OCR ошибся — база поправила. Никакой магии, просто аккуратно использованные инструменты. Похожий подход, кстати, используется и в FineReader.
Параллельно открыл свой старый проект на NodeJS. Посмотрел код и поймал странное ощущение: вроде бы писал я, но читать больно. Очень быстро становится понятно, как растёшь — по тому, насколько раздражает собственный код из прошлого.
Отдельный цирк был с AI-агентом. Сломалась сборка из-за библиотеки figlet, и «умное» решение оказалось простым: удалить библиотеку и захардкодить ascii-арт. Логика железная. Пришлось руками дожимать до нормального решения и заменить на cfonts. В очередной раз убедился: AI отлично ускоряет, но мусора генерирует не меньше.
В итоге для CLI-интерфейса взял @clack/prompts https://www.npmjs.com/package/@clack/prompts — неожиданно аккуратная библиотека. Минимум лишнего, всё работает как надо.
Чем дальше копаюсь в таких задачах, тем яснее вижу: проблема редко в «сложной технологии». Обычно всё ломается на стыке — OCR, данные, логика. И вот там уже начинается настоящая работа.
👍3
Хотел просто переименовать файлы — получил счёт на тысячу рублей.
Начал делать CLI-утилиту smart-renamer https://github.com/orion55/smart-renamer — автоматическое переименование медиафайлов с переводом названий на русский через YandexGPT. На входе обычный «зоопарк» скачанных файлов вроде:
На выходе хочется получить что-то человеческое:
Идея простая, а реализация — как обычно: начинаешь с пары строк кода, заканчиваешь разбором чужих ошибок и собственных иллюзий.
Сначала попробовал через Яндекс.Переводчик. На выходе получается полная дичь. Английские и русские названия фильмов живут своей жизнью и редко совпадают. Решил пойти «умнее» — подключить AI. Написал жирный промпт, добавил логику «если не знаешь — сходи в интернет», взял YandexGPT 5.1 Pro, включил многопоточность, ретраи — всё как положено.
И тут началось. Агент стабильно падал по токенам. Оказалось, модель не знает название фильма — идёт в интернет, тянет кучу данных, упирается в лимиты и отваливается. Параллельно вся эта многопоточка с ретраями за пару часов сожрала около 1000 рублей. Очень наглядный урок: мощная модель легко превращается в пылесос для бюджета.
В итоге выкинул всё это великолепие и поставил более простую модель Alice AI LLM. И внезапно всё заработало: без интернета, без ретраев, без параллелизма. Просто возвращает нужные названия. Вывод банальный, но неприятный: «умнее» не значит «лучше», особенно когда платишь за каждый токен.
Отдельный бонус — код от Claude. Поймал странный баг: функция ничего не возвращает, хотя должна. Начал разбираться — а там тихо мутируется исходный массив. Та самая классика с тихими, почти невидимыми side-эффектами. По факту — глупая новичковая ошибка: не уследил за мутацией и сам себе сломал логику. Та самая ситуация, где «всё вроде правильно», но не работает. Когда ткнул в это ИИ носом — исправилось. А если бы не ткнул?
В итоге вся эта история не про переименование файлов. Она про контроль. За моделью, за кодом, за деньгами. Иначе очень быстро начинаешь платить за ошибки, которые даже не видишь.
Начал делать CLI-утилиту smart-renamer https://github.com/orion55/smart-renamer — автоматическое переименование медиафайлов с переводом названий на русский через YandexGPT. На входе обычный «зоопарк» скачанных файлов вроде:
The.Walking.Dead.S05E03.720p.BluRay.x264-DEMAND.mkv
Game.of.Thrones.2011.S01E01.WEB-DL.1080p.mkv
Pochuvstvuj.moj.golos.2026.NF.WEB-DLRip.AVC/
На выходе хочется получить что-то человеческое:
Ходячие мертвецы/0503.mkv
Игра престолов/01.mkv
Почувствуй мой голос.mkv
Идея простая, а реализация — как обычно: начинаешь с пары строк кода, заканчиваешь разбором чужих ошибок и собственных иллюзий.
Сначала попробовал через Яндекс.Переводчик. На выходе получается полная дичь. Английские и русские названия фильмов живут своей жизнью и редко совпадают. Решил пойти «умнее» — подключить AI. Написал жирный промпт, добавил логику «если не знаешь — сходи в интернет», взял YandexGPT 5.1 Pro, включил многопоточность, ретраи — всё как положено.
И тут началось. Агент стабильно падал по токенам. Оказалось, модель не знает название фильма — идёт в интернет, тянет кучу данных, упирается в лимиты и отваливается. Параллельно вся эта многопоточка с ретраями за пару часов сожрала около 1000 рублей. Очень наглядный урок: мощная модель легко превращается в пылесос для бюджета.
В итоге выкинул всё это великолепие и поставил более простую модель Alice AI LLM. И внезапно всё заработало: без интернета, без ретраев, без параллелизма. Просто возвращает нужные названия. Вывод банальный, но неприятный: «умнее» не значит «лучше», особенно когда платишь за каждый токен.
Отдельный бонус — код от Claude. Поймал странный баг: функция ничего не возвращает, хотя должна. Начал разбираться — а там тихо мутируется исходный массив. Та самая классика с тихими, почти невидимыми side-эффектами. По факту — глупая новичковая ошибка: не уследил за мутацией и сам себе сломал логику. Та самая ситуация, где «всё вроде правильно», но не работает. Когда ткнул в это ИИ носом — исправилось. А если бы не ткнул?
В итоге вся эта история не про переименование файлов. Она про контроль. За моделью, за кодом, за деньгами. Иначе очень быстро начинаешь платить за ошибки, которые даже не видишь.
GitHub
GitHub - orion55/smart-renamer
Contribute to orion55/smart-renamer development by creating an account on GitHub.
👍5
Попросил ИИ «сделать как лучше» — и получил совсем не то, что нужно.
На работе делаю упрощённую внутреннюю админку для телефонии и решил активно подключить ИИ. В какой-то момент отпустил контроль — и на простое приложение для 2–3 админов внезапно была реализована двухуровневая аутентификация. При том, что логина и пароля там более чем достаточно. Хорошее напоминание: ИИ ускоряет, но думать за тебя не будет.
С дизайном история вышла не менее показательная. Решил «пусть сам предложит концепт» — и получил: «Signal Console», тёмная панель в стиле профессиональных коммутаторов, монохромный шрифт, LED‑индикаторы, кислотный циан. Звучит красиво, но по факту это просто внутренняя админка. Киберпанк там лишний.
С фронтендом ещё веселее. ИИ решил не использовать готовые библиотеки и начал писать всё с нуля, включая таблицу со сортировками, фильтрацией и пагинацией. Уже проходил это на проекте — через спринт такие идеи умирают. Пришлось аккуратно объяснять, что «изобретать таблицу» — путь в никуда.
Параллельно решил перейти с npm на pnpm. Разница простая: npm тащит зависимости прямо в проект и дублирует их, из-за чего всё разрастается. pnpm хранит пакеты глобально и подсовывает их через hard links — быстрее и заметно экономит место. Пока разбираюсь, но подход выглядит разумнее.
Начал читать «Грокаем машинное обучение» Луиса Серрано. Книга заявлена как «для самых маленьких», без сложной математики и с простым Python. Но даже так читается тяжело. А если открыть приложение с формулами — производные, интегралы — становится понятно, где заканчивается «игра с ИИ» и начинается настоящее машинное обучение.
Вывод простой: ИИ — это инструмент. Если его не ограничивать, он легко уедет в оверинжиниринг, красивый, но бесполезный. В какой-то момент всё равно приходится включать голову и возвращать задачу к реальности.
На работе делаю упрощённую внутреннюю админку для телефонии и решил активно подключить ИИ. В какой-то момент отпустил контроль — и на простое приложение для 2–3 админов внезапно была реализована двухуровневая аутентификация. При том, что логина и пароля там более чем достаточно. Хорошее напоминание: ИИ ускоряет, но думать за тебя не будет.
С дизайном история вышла не менее показательная. Решил «пусть сам предложит концепт» — и получил: «Signal Console», тёмная панель в стиле профессиональных коммутаторов, монохромный шрифт, LED‑индикаторы, кислотный циан. Звучит красиво, но по факту это просто внутренняя админка. Киберпанк там лишний.
С фронтендом ещё веселее. ИИ решил не использовать готовые библиотеки и начал писать всё с нуля, включая таблицу со сортировками, фильтрацией и пагинацией. Уже проходил это на проекте — через спринт такие идеи умирают. Пришлось аккуратно объяснять, что «изобретать таблицу» — путь в никуда.
Параллельно решил перейти с npm на pnpm. Разница простая: npm тащит зависимости прямо в проект и дублирует их, из-за чего всё разрастается. pnpm хранит пакеты глобально и подсовывает их через hard links — быстрее и заметно экономит место. Пока разбираюсь, но подход выглядит разумнее.
Начал читать «Грокаем машинное обучение» Луиса Серрано. Книга заявлена как «для самых маленьких», без сложной математики и с простым Python. Но даже так читается тяжело. А если открыть приложение с формулами — производные, интегралы — становится понятно, где заканчивается «игра с ИИ» и начинается настоящее машинное обучение.
Вывод простой: ИИ — это инструмент. Если его не ограничивать, он легко уедет в оверинжиниринг, красивый, но бесполезный. В какой-то момент всё равно приходится включать голову и возвращать задачу к реальности.
👍4❤1
Иногда проблема не в сложности задач, а в том, сколько лишних движений вокруг них.
Закрываешь проект — и вдруг видишь, где утекают часы.
На работе довёл до конца упрощённую внутреннюю админку для телефонии. Заодно аккуратно дожал DevOps-часть, без лишнего фанатизма — ровно столько, сколько нужно, чтобы не страдать потом на деплое.
Нашёл для себя очень удобную штуку — https://github.com/jesseduffield/lazydocker
Lazydocker — это терминальный интерфейс для управления Docker-контейнерами, образами и сетями в реальном времени. По сути, всё то же самое, что делаешь руками через CLI, только без простыней команд. Логи, перезапуск, удаление, мониторинг — всё под рукой. Для диагностики и администрирования из консоли — прям то, что нужно.
С установкой, правда, есть нюанс. Не сказать, что сложно, но и не «apt install и поехали»:
Раньше, чтобы просто посмотреть логи нужного контейнера, приходилось продираться через команды, вспоминать имена, искать нужное. Сейчас — открыл один инструмент и сразу видишь всё. Мелочь, а экономит кучу сил.
Посмотрел видео «AI-программист за 500 рублей: правда об агентском кодинге» https://www.youtube.com/watch?v=CjHFdsTW4ug
Обычно такие видео либо про «всё уже заменили нейросети», либо «всё пропало». Здесь редкий случай — спокойный разбор и реальный опыт без крайностей. Смотришь и понимаешь, где это работает, а где пока нет.
Claude в очередной раз улетел в бан. Продавец аккаунта руками разводит — остаётся только ждать. Решил не зависеть от одного инструмента и попробовать альтернативы. Наткнулся на https://kilo.ai/
Kilo AI — open-source ассистент для разработки, который встраивается в IDE и работает не только с отдельными кусками кода, а с проектом целиком.
Интересный момент — поддержка внешних провайдеров через API. Есть, например, OpenRouter — прокси-слой к разным LLM (Claude, GPT, Mistral и др.). Получается, можно не завязываться на одного вендора и переключаться по ситуации.
В итоге картина складывается простая. С одной стороны — инструменты вроде lazydocker, которые экономят время здесь и сейчас. С другой — AI, который пока ещё требует контроля, но уже начинает забирать на себя рутину. Вопрос не в том, заменит или нет, а в том, где именно он реально полезен.
Закрываешь проект — и вдруг видишь, где утекают часы.
На работе довёл до конца упрощённую внутреннюю админку для телефонии. Заодно аккуратно дожал DevOps-часть, без лишнего фанатизма — ровно столько, сколько нужно, чтобы не страдать потом на деплое.
Нашёл для себя очень удобную штуку — https://github.com/jesseduffield/lazydocker
Lazydocker — это терминальный интерфейс для управления Docker-контейнерами, образами и сетями в реальном времени. По сути, всё то же самое, что делаешь руками через CLI, только без простыней команд. Логи, перезапуск, удаление, мониторинг — всё под рукой. Для диагностики и администрирования из консоли — прям то, что нужно.
С установкой, правда, есть нюанс. Не сказать, что сложно, но и не «apt install и поехали»:
export DIR=/usr/local/bin
curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash
lazydocker
Раньше, чтобы просто посмотреть логи нужного контейнера, приходилось продираться через команды, вспоминать имена, искать нужное. Сейчас — открыл один инструмент и сразу видишь всё. Мелочь, а экономит кучу сил.
Посмотрел видео «AI-программист за 500 рублей: правда об агентском кодинге» https://www.youtube.com/watch?v=CjHFdsTW4ug
Обычно такие видео либо про «всё уже заменили нейросети», либо «всё пропало». Здесь редкий случай — спокойный разбор и реальный опыт без крайностей. Смотришь и понимаешь, где это работает, а где пока нет.
Claude в очередной раз улетел в бан. Продавец аккаунта руками разводит — остаётся только ждать. Решил не зависеть от одного инструмента и попробовать альтернативы. Наткнулся на https://kilo.ai/
Kilo AI — open-source ассистент для разработки, который встраивается в IDE и работает не только с отдельными кусками кода, а с проектом целиком.
Интересный момент — поддержка внешних провайдеров через API. Есть, например, OpenRouter — прокси-слой к разным LLM (Claude, GPT, Mistral и др.). Получается, можно не завязываться на одного вендора и переключаться по ситуации.
В итоге картина складывается простая. С одной стороны — инструменты вроде lazydocker, которые экономят время здесь и сейчас. С другой — AI, который пока ещё требует контроля, но уже начинает забирать на себя рутину. Вопрос не в том, заменит или нет, а в том, где именно он реально полезен.
GitHub
GitHub - jesseduffield/lazydocker: The lazier way to manage everything docker
The lazier way to manage everything docker. Contribute to jesseduffield/lazydocker development by creating an account on GitHub.
👍5
На ближайшие две недели немного выпадаю из онлайна.
Уезжаю в отпуск на Кавказ. Горы, дороги, тишина и попытка хотя бы ненадолго перестать думать про телефонию, Docker, Asterisk и бесконечные логи.
Последние месяцы прошли в режиме «то чат-бот, то голосовое меню, то очередной сюрприз от операторов связи». В какой-то момент поймал себя на мысли, что уже автоматически читаю логи даже в выходные. Пора сделать паузу, перезагрузить голову и посмотреть на что-то сложнее Kubernetes — на горы.
Так что если внезапно пропаду, не потерялся.
Вернусь через две недели с новыми историями, наблюдениями и, скорее всего, очередной технической эпопеей.
Уезжаю в отпуск на Кавказ. Горы, дороги, тишина и попытка хотя бы ненадолго перестать думать про телефонию, Docker, Asterisk и бесконечные логи.
Последние месяцы прошли в режиме «то чат-бот, то голосовое меню, то очередной сюрприз от операторов связи». В какой-то момент поймал себя на мысли, что уже автоматически читаю логи даже в выходные. Пора сделать паузу, перезагрузить голову и посмотреть на что-то сложнее Kubernetes — на горы.
Так что если внезапно пропаду, не потерялся.
Вернусь через две недели с новыми историями, наблюдениями и, скорее всего, очередной технической эпопеей.
❤6👍3
Съездил на Кавказ и быстро понял: это не отпуск в формате «полежать и отдохнуть». Это когда утром ты идёшь «немного прогуляться», а вечером часы поздравляют тебя с 10 000 шагов, ноги молчат от обиды, а впереди ещё горы, ущелья и дождь с градом.
В статье рассказал про поездку в Кабардино-Балкарию: Нальчик, Чегемское ущелье, Голубые озёра, Эльбрус, Адыр-Су, термальные источники, местные музеи и одну «мистическую шахту», которую специалисты из высокого интернета уже успели записать в работу неандертальцев и инопланетян.
Получился не рекламный тревелог, а честный рассказ: где красиво, где переоценено, где промок, где устал, а где понял, что на Эльбрус без подготовки лезть не надо.
Полная статья здесь:
https://vk.com/@grebenyov-puteshestvie-v-kabardino-balkariu-stranu-chudes
В статье рассказал про поездку в Кабардино-Балкарию: Нальчик, Чегемское ущелье, Голубые озёра, Эльбрус, Адыр-Су, термальные источники, местные музеи и одну «мистическую шахту», которую специалисты из высокого интернета уже успели записать в работу неандертальцев и инопланетян.
Получился не рекламный тревелог, а честный рассказ: где красиво, где переоценено, где промок, где устал, а где понял, что на Эльбрус без подготовки лезть не надо.
Полная статья здесь:
https://vk.com/@grebenyov-puteshestvie-v-kabardino-balkariu-stranu-chudes
VK
Путешествие в Кабардино-Балкарию — страну чудес
В этом году я решил съездить на Кавказ. Не в формате «пляж — рынок — гостиница», а нормально: горы, ущелья, музеи, дождь, грязь, термальн..
👍5❤2
Возвращение из отпуска — это отдельный вид онбординга. Вроде тебя не было всего три недели, а рабочие процессы уже лежат в голове где-то в архиве без индекса. Сидишь, вспоминаешь детали, нюансы, странные договорённости, и постепенно мозг снова начинает загружать рабочую конфигурацию. Кажется, всё вспомнил. По крайней мере, пока ничего критичного не забыл.
Параллельно посмотрел видео «Почему все проваливают алгоритмические собеседования?» https://www.youtube.com/watch?v=u_c3WCpEUzY. И в очередной раз понял простую вещь: алгоритмические собеседования — это не проверка «умный ты или нет», а отдельный навык. Его нужно просто нарабатывать. Поэтому поставил себе цель — решить 100 задач. Минимальный план пока простой: хотя бы одна задача в день.
Это сильно напоминает изучение английского. Сначала кажется, что ты почти всё знаешь, а потом реальность аккуратно бьёт по голове учебником грамматики. Мои первые иллюзии о собственном уровне английского оказались, мягко говоря, завышенными. До B1 я шёл примерно 2–3 года. Алгоритмы по объёму меньше английского, но своих нюансов там хватает, и они тоже не прощают самоуверенности.
Начал проходить LeetCode Explore https://leetcode.com/explore/, там много обучающих блоков. Для старта взял Array and String https://leetcode.com/explore/learn/card/array-and-string/. И довольно быстро выяснилось, что самые коварные задачи часто формулируются в одну строку. Вроде читаешь условие — всё понятно. Потом садишься решать — и внезапно понимаешь, что понятным было только первое предложение.
Например, Diagonal Traverse https://leetcode.com/explore/learn/card/array-and-string/202/introduction-to-2d-array/1167/ — нужно просто обойти матрицу по диагонали. Просто, ага. Без ИИ я не догадался, что у элементов на одной диагонали одинаковая сумма индексов, а каждую чётную диагональ нужно разворачивать при формировании ответа. Формально задача маленькая, но идея в ней спрятана очень аккуратно.
Или Two Sum II - Input array is sorted https://leetcode.com/explore/learn/card/array-and-string/205/introduction-to-2d-array/1153/. Вроде классика: два указателя, отсортированный массив, ищем сумму. Но потом всплывает, что индексы в ответе начинаются с 1, а не с 0. Мелочь, но именно такие мелочи и ломают решение. Так что LeetCode — это отдельный вид искусства, где важно не только решить, но и внимательно прочитать условие.
На работе тоже возникла интересная задача: нужно интегрировать 1С и Asterisk, чтобы менеджеры по продажам могли звонить прямо из 1С. Интеграцию делал через продукт 1С:Рарус https://rarus.ru/. Решение занимательное: ставится софт-прослойка между 1С и Asterisk. К Asterisk он подключается через AMI — Asterisk Manager Interface, а в 1С встраивается в виде расширения.
Про популярные способы интеграции с Asterisk я уже писал в статье «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a. В этот раз теория пригодилась на практике. Вместе с программистом 1С всё настроили: звонки идут туда и обратно. Менеджеры могут звонить из 1С, Asterisk честно отрабатывает свою часть.
Но, как обычно, на слове «готово» история не заканчивается. Звонки уже работают, а вот записи разговоров из 1С пока послушать не удаётся. Значит, дальше будет отдельный слой веселья: пути к файлам, имена записей, AMI-события, права доступа и всё то, что обычно прячется за фразой «осталось только подключить записи». Буду думать дальше.
Итог недели простой: после отпуска мозг перезагрузился не сразу, но запустился. Алгоритмы снова напомнили, что навык появляется только через практику, а рабочая телефония — что любая интеграция почти всегда сложнее, чем выглядит в инструкции. Зато скучно не было. А это уже почти рабочий успех.
Параллельно посмотрел видео «Почему все проваливают алгоритмические собеседования?» https://www.youtube.com/watch?v=u_c3WCpEUzY. И в очередной раз понял простую вещь: алгоритмические собеседования — это не проверка «умный ты или нет», а отдельный навык. Его нужно просто нарабатывать. Поэтому поставил себе цель — решить 100 задач. Минимальный план пока простой: хотя бы одна задача в день.
Это сильно напоминает изучение английского. Сначала кажется, что ты почти всё знаешь, а потом реальность аккуратно бьёт по голове учебником грамматики. Мои первые иллюзии о собственном уровне английского оказались, мягко говоря, завышенными. До B1 я шёл примерно 2–3 года. Алгоритмы по объёму меньше английского, но своих нюансов там хватает, и они тоже не прощают самоуверенности.
Начал проходить LeetCode Explore https://leetcode.com/explore/, там много обучающих блоков. Для старта взял Array and String https://leetcode.com/explore/learn/card/array-and-string/. И довольно быстро выяснилось, что самые коварные задачи часто формулируются в одну строку. Вроде читаешь условие — всё понятно. Потом садишься решать — и внезапно понимаешь, что понятным было только первое предложение.
Например, Diagonal Traverse https://leetcode.com/explore/learn/card/array-and-string/202/introduction-to-2d-array/1167/ — нужно просто обойти матрицу по диагонали. Просто, ага. Без ИИ я не догадался, что у элементов на одной диагонали одинаковая сумма индексов, а каждую чётную диагональ нужно разворачивать при формировании ответа. Формально задача маленькая, но идея в ней спрятана очень аккуратно.
Или Two Sum II - Input array is sorted https://leetcode.com/explore/learn/card/array-and-string/205/introduction-to-2d-array/1153/. Вроде классика: два указателя, отсортированный массив, ищем сумму. Но потом всплывает, что индексы в ответе начинаются с 1, а не с 0. Мелочь, но именно такие мелочи и ломают решение. Так что LeetCode — это отдельный вид искусства, где важно не только решить, но и внимательно прочитать условие.
На работе тоже возникла интересная задача: нужно интегрировать 1С и Asterisk, чтобы менеджеры по продажам могли звонить прямо из 1С. Интеграцию делал через продукт 1С:Рарус https://rarus.ru/. Решение занимательное: ставится софт-прослойка между 1С и Asterisk. К Asterisk он подключается через AMI — Asterisk Manager Interface, а в 1С встраивается в виде расширения.
Про популярные способы интеграции с Asterisk я уже писал в статье «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a. В этот раз теория пригодилась на практике. Вместе с программистом 1С всё настроили: звонки идут туда и обратно. Менеджеры могут звонить из 1С, Asterisk честно отрабатывает свою часть.
Но, как обычно, на слове «готово» история не заканчивается. Звонки уже работают, а вот записи разговоров из 1С пока послушать не удаётся. Значит, дальше будет отдельный слой веселья: пути к файлам, имена записей, AMI-события, права доступа и всё то, что обычно прячется за фразой «осталось только подключить записи». Буду думать дальше.
Итог недели простой: после отпуска мозг перезагрузился не сразу, но запустился. Алгоритмы снова напомнили, что навык появляется только через практику, а рабочая телефония — что любая интеграция почти всегда сложнее, чем выглядит в инструкции. Зато скучно не было. А это уже почти рабочий успех.
YouTube
Почему все проваливают алгоритмические собеседования?
❗️Бесплатный курс по структурам данных и асимптотическому анализу: https://clck.ru/3RnjNA
Потренироваться проходить собеседования: https://clck.ru/3Rni4b
Найти напарника для подготовки к собеседованиям: https://clck.ru/3Rni6X
ROADMAP по LeetCode: https:…
Потренироваться проходить собеседования: https://clck.ru/3Rni4b
Найти напарника для подготовки к собеседованиям: https://clck.ru/3Rni6X
ROADMAP по LeetCode: https:…
👍5
На работе возникла задача проверить, безопасен ли код, который пишут наши программисты. Спойлер: нет. И почти сразу появилась «гениальная идея»: давайте внедрим SonarQube, прогоним код через линтер — и всё узнаем.
К сожалению, один линтер не сделает код безопасным. Безопасность приложения — это не одна галочка в CI/CD, а несколько уровней контроля: код, зависимости, Docker-образы, конфигурации, секреты, права доступа и поведение приложения после деплоя.
На уровне кода нужны SAST-инструменты и линтеры. Они помогают находить потенциальные уязвимости ещё до сборки и выката: небезопасную работу с входными данными, SQL-инъекции, XSS, ошибки авторизации и другие проблемные места. Здесь могут пригодиться SonarQube, GitLab SAST, Semgrep.
Отдельно нужно проверять зависимости. Даже если собственный код написан аккуратно, уязвимость может приехать через стороннюю библиотеку. Для этого подходят GitLab Dependency Scanning, OWASP Dependency-Check, Snyk, потому что безопасность ломается не только там, где писал ты сам.
Secret Detection нужен, чтобы не утащить в репозиторий токены, пароли, приватные ключи, API-ключи и другие секреты. Это отдельная боль: один случайно закоммиченный
Container scanning нужен, чтобы не тащить в production уязвимые базовые образы и системные пакеты. Здесь можно использовать GitLab Container Scanning, Trivy, Grype, Clair, Snyk Container. Отдельная история — DAST: он проверяет уже работающее приложение как «чёрный ящик» и показывает проблемы, которые проявляются только в запущенной системе.
Есть ещё инфраструктурная безопасность: права доступа, сетевые политики, секреты, централизованная авторизация, аудит и мониторинг. Это уже не про один сканер, а про общую дисциплину эксплуатации: кто имеет доступ, где лежат секреты, какие действия логируются и как быстро можно заметить проблему после деплоя.
Вывод простой: линтер — это только первая линия обороны. Нормальная безопасность начинается там, где проверки закрывают весь путь приложения: от кода, зависимостей и секретов до контейнера, инфраструктуры и реального поведения в production. Всё остальное — приятная иллюзия контроля.
Вот хорошие видео на эту тему.
DevSecOps для самых маленьких
https://www.youtube.com/watch?v=jdSyadPFycE
С какого конца начинать безопасную разработку
https://www.youtube.com/watch?v=UHD0q8QW_rM
А теперь немного новостей. У компании Rebrain летом появился формат «Открытый микрофон»: каждый может прийти со своим докладом и выступить на аудиторию. Я подумал: а почему бы и да, у меня же есть статья «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a
Я выполнил необходимые требования к спикеру, и мой доклад приняли. Так что 24 июня проведу вебинар на тему статьи. Можно зарегистрироваться здесь: https://rebrainme.com/webinars
Открою тайну: доклад, презентация и демонстрации ещё не готовы. Точнее готовы, но не до конца. Но за две недели я точно их доделаю, потому что инженерная магия обычно начинается сразу после слов «ну тут осталось совсем немного».
К сожалению, один линтер не сделает код безопасным. Безопасность приложения — это не одна галочка в CI/CD, а несколько уровней контроля: код, зависимости, Docker-образы, конфигурации, секреты, права доступа и поведение приложения после деплоя.
На уровне кода нужны SAST-инструменты и линтеры. Они помогают находить потенциальные уязвимости ещё до сборки и выката: небезопасную работу с входными данными, SQL-инъекции, XSS, ошибки авторизации и другие проблемные места. Здесь могут пригодиться SonarQube, GitLab SAST, Semgrep.
Отдельно нужно проверять зависимости. Даже если собственный код написан аккуратно, уязвимость может приехать через стороннюю библиотеку. Для этого подходят GitLab Dependency Scanning, OWASP Dependency-Check, Snyk, потому что безопасность ломается не только там, где писал ты сам.
Secret Detection нужен, чтобы не утащить в репозиторий токены, пароли, приватные ключи, API-ключи и другие секреты. Это отдельная боль: один случайно закоммиченный
.env или ключ доступа может стоить дороже, чем десяток замечаний от линтера. Для таких проверок можно использовать GitLab Secret Detection, Gitleaks, TruffleHog, detect-secrets, GitGuardian.Container scanning нужен, чтобы не тащить в production уязвимые базовые образы и системные пакеты. Здесь можно использовать GitLab Container Scanning, Trivy, Grype, Clair, Snyk Container. Отдельная история — DAST: он проверяет уже работающее приложение как «чёрный ящик» и показывает проблемы, которые проявляются только в запущенной системе.
Есть ещё инфраструктурная безопасность: права доступа, сетевые политики, секреты, централизованная авторизация, аудит и мониторинг. Это уже не про один сканер, а про общую дисциплину эксплуатации: кто имеет доступ, где лежат секреты, какие действия логируются и как быстро можно заметить проблему после деплоя.
Вывод простой: линтер — это только первая линия обороны. Нормальная безопасность начинается там, где проверки закрывают весь путь приложения: от кода, зависимостей и секретов до контейнера, инфраструктуры и реального поведения в production. Всё остальное — приятная иллюзия контроля.
Вот хорошие видео на эту тему.
DevSecOps для самых маленьких
https://www.youtube.com/watch?v=jdSyadPFycE
С какого конца начинать безопасную разработку
https://www.youtube.com/watch?v=UHD0q8QW_rM
А теперь немного новостей. У компании Rebrain летом появился формат «Открытый микрофон»: каждый может прийти со своим докладом и выступить на аудиторию. Я подумал: а почему бы и да, у меня же есть статья «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a
Я выполнил необходимые требования к спикеру, и мой доклад приняли. Так что 24 июня проведу вебинар на тему статьи. Можно зарегистрироваться здесь: https://rebrainme.com/webinars
Открою тайну: доклад, презентация и демонстрации ещё не готовы. Точнее готовы, но не до конца. Но за две недели я точно их доделаю, потому что инженерная магия обычно начинается сразу после слов «ну тут осталось совсем немного».
YouTube
DevSecOps для самых маленьких. Иван Кондратьев | KazHackStan 2022
В докладе мы рассмотрим различный инструментарий, как opensource так и enterprise, который повысит качество разрабатываемого кода (продукта) в контексте информациионной безопасности.
👍3
Почти всю неделю на работе настраивал SonarQube. Задача из тех, которые сначала выглядят как «ну сейчас быстро подключим», а потом внезапно превращаются в квест с токенами, правами, GitLab и кучей мелких нюансов. Чтобы нормально связать GitLab и SonarQube, нужна туева хуча разных токенов с разными правами. Но я справился.
Сканирование нашего основного проекта занимает примерно 20–30 минут. Важно понимать: SonarQube сканирует весь проект, а не отдельные коммиты. Для проверки коммитов лучше использовать GitLab SAST, но это уже задача на следующую неделю. Один инструмент не закрывает всю безопасность, он просто подсвечивает часть проблем.
Посмотрел результаты сканирования — наш код, мягко говоря, не безопасный. Я даже не думал, что можно допускать такие банальные ошибки, но проект старый, поэтому возможно всё. Хорошая новость в том, что самые критические проблемы уже пофиксили. Плохая — теперь понятно, сколько ещё работы впереди.
По SonarQube рекомендую два видео:
«Никита Грызлов. Мастер-класс. SonarQube. В омут с головой» https://www.youtube.com/watch?v=wFwG8bKuEw4
«Святослав Кокурин из Naumen “Внедряем SonarQube без шума и пыли”» https://www.youtube.com/watch?v=LI36tWHd-Tc
SonarQube — мощная и сложная система промышленного уровня. Если смотрите в сторону DevSecOps, разобраться с ней точно стоит.
В пятницу прилетела ещё одна задача. На проде периодически падают сервисы-консьюмеры, которые обрабатывают очереди RabbitMQ. Только падают они хитро: процессы в системе есть, память и процессор потребляют, вроде бы «работают», но очереди уже не обрабатывают. Формально живые, по факту бесполезные.
Решили реализовать временный костыль. Если количество консьюмеров по очереди становится равно нулю, в Zabbix срабатывает триггер, который запускает скрипт и убивает нужный сервис на проде. Эти сервисы автоматически стартуют каждую минуту, поэтому простой минимальный. Более правильно, конечно, задать программистам вопрос: почему код зависает. Но по собственному опыту знаю: поймать плавающую ошибку, которая возникает раз в несколько дней, — отдельный вид боли.
Bash-скрипт, который убивает сервис по SSH, я написал. Главный вопрос был в другом: как проверить его работу и не устроить пожар на проде. Если специально ронять рабочие службы, меня сожгут где-нибудь между переговоркой и серверной. А Zabbix ещё и выполняет скрипты довольно молча: сработало, не сработало, где упало — разбирайся сам.
В итоге сделал фейковый Item
Получилась вполне рабочая схема: сам создал ошибку, сам её обработал, сам проверил цепочку от Zabbix до скрипта. И главное — на проде ничего ломать не пришлось. Иногда лучший тест — это не героически уронить боевую систему, а спокойно собрать безопасную имитацию проблемы.
Кстати, напоминаю: в следующую среду, 24 июня 2026 года, в 18:00 по МСК, я провожу вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» https://rebrainme.com/webinars/kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-asterisk-na-praktike
Приходите, расскажу про программирование Asterisk, Dialplan, AGI, AMI, ARI и про тот момент, когда обычная телефония внезапно превращается в разработку.
Сканирование нашего основного проекта занимает примерно 20–30 минут. Важно понимать: SonarQube сканирует весь проект, а не отдельные коммиты. Для проверки коммитов лучше использовать GitLab SAST, но это уже задача на следующую неделю. Один инструмент не закрывает всю безопасность, он просто подсвечивает часть проблем.
Посмотрел результаты сканирования — наш код, мягко говоря, не безопасный. Я даже не думал, что можно допускать такие банальные ошибки, но проект старый, поэтому возможно всё. Хорошая новость в том, что самые критические проблемы уже пофиксили. Плохая — теперь понятно, сколько ещё работы впереди.
По SonarQube рекомендую два видео:
«Никита Грызлов. Мастер-класс. SonarQube. В омут с головой» https://www.youtube.com/watch?v=wFwG8bKuEw4
«Святослав Кокурин из Naumen “Внедряем SonarQube без шума и пыли”» https://www.youtube.com/watch?v=LI36tWHd-Tc
SonarQube — мощная и сложная система промышленного уровня. Если смотрите в сторону DevSecOps, разобраться с ней точно стоит.
В пятницу прилетела ещё одна задача. На проде периодически падают сервисы-консьюмеры, которые обрабатывают очереди RabbitMQ. Только падают они хитро: процессы в системе есть, память и процессор потребляют, вроде бы «работают», но очереди уже не обрабатывают. Формально живые, по факту бесполезные.
Решили реализовать временный костыль. Если количество консьюмеров по очереди становится равно нулю, в Zabbix срабатывает триггер, который запускает скрипт и убивает нужный сервис на проде. Эти сервисы автоматически стартуют каждую минуту, поэтому простой минимальный. Более правильно, конечно, задать программистам вопрос: почему код зависает. Но по собственному опыту знаю: поймать плавающую ошибку, которая возникает раз в несколько дней, — отдельный вид боли.
Bash-скрипт, который убивает сервис по SSH, я написал. Главный вопрос был в другом: как проверить его работу и не устроить пожар на проде. Если специально ронять рабочие службы, меня сожгут где-нибудь между переговоркой и серверной. А Zabbix ещё и выполняет скрипты довольно молча: сработало, не сработало, где упало — разбирайся сам.
В итоге сделал фейковый Item
test.trigger, который меняю через команду zabbix_sender -z 127.0.0.1 -s "rabbitmq" -k test.trigger -o 1. К нему привязал тестовый триггер, который запускает мой скрипт. Отладку делал через логи, потому что без логов в таких задачах быстро начинается гадание на кофейной гуще. Когда ошибка больше не нужна, возвращаю всё обратно: zabbix_sender -z 127.0.0.1 -s "rabbitmq" -k test.trigger -o 0.Получилась вполне рабочая схема: сам создал ошибку, сам её обработал, сам проверил цепочку от Zabbix до скрипта. И главное — на проде ничего ломать не пришлось. Иногда лучший тест — это не героически уронить боевую систему, а спокойно собрать безопасную имитацию проблемы.
Кстати, напоминаю: в следующую среду, 24 июня 2026 года, в 18:00 по МСК, я провожу вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» https://rebrainme.com/webinars/kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-asterisk-na-praktike
Приходите, расскажу про программирование Asterisk, Dialplan, AGI, AMI, ARI и про тот момент, когда обычная телефония внезапно превращается в разработку.
YouTube
Никита Грызлов. Мастер-класс. SonarQube. В омут с головой
Поговорим про SonarQube – не только о том, что он может дать, но и о том, как его установить, быстро запустить и произвести в нем базовые настройки.
Доклад в виде статьи: https://infostart.ru/public/1661973/
Доклад в виде статьи: https://infostart.ru/public/1661973/
👍5❤1
Иногда одна демонстрация на вебинаре превращается в две недели борьбы с окружением, зависимостями и чужими настройками. А одна строка в
Провёл вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» на Rebrain. И понял одну простую вещь: самое сложное в докладе — не выступление, а всё, что происходит до него.
Тему я заявлял как обзор технологий Asterisk для разработчиков. Планировал рассказать про четыре инструмента: Dialplan, AGI (Asterisk Gateway Interface), AMI (Asterisk Manager Interface) и ARI (Asterisk REST Interface).
Но реальность быстро внесла свои коррективы. Выяснилось, что ARI даже для простого примера требует слишком глубокого погружения. Тратить несколько недель только ради одной демонстрации не хотелось, поэтому пришлось отказаться.
Со всем остальным тоже оказалось не так просто. На работе эти технологии давно функционируют, и я уже не замечаю, насколько большое окружение за ними стоит. Например, для демонстрации AMI понадобился CDR. Начал поднимать всё с нуля — и сразу выяснилось, что «из коробки» оно не работает.
CDR потребовал MySQL. MySQL оказался привязан не к тому интерфейсу. Исправил. Затем выяснилось, что структура базы данных не подходит под мою версию Asterisk. Переделал. Чтобы показать простую функцию — соединить клиента с тем менеджером, с которым он разговаривал ранее, — пришлось буквально перешерстить полобраза Ubuntu.
Потом решил выложить исходники на GitHub. Часть проекта работала в Docker, поэтому пришлось ещё разбираться с GitHub Actions, чтобы автоматически публиковать Docker-образы. Огромный пласт работы, который никто во время вебинара даже не увидит.
И так было практически с каждой демонстрацией. Со стороны кажется: «показать небольшой пример». На практике — две недели настройки, поиска несовместимостей и чтения документации.
В итоге всё заработало. Но появилась другая проблема. Доклад, который я рассчитывал провести за полтора часа, уложился примерно в сорок минут.
На вебинар зарегистрировались 115 человек. Формат был «открытый микрофон»: после выступления можно заполнить анкету с обратной связью.
И тут финальный штрих.
Анкету заполнил... один человек.
Возможно, тема оказалась слишком узкой. Менеджер Rebrain уже предложила выступить ещё раз в августе. Похоже, в следующий раз придётся выбирать что-то более массовое. Узкоспециализированные темы интересны далеко не всем.
На работе тоже приключение.
Написал скрипт. Всё работает, но он пишет логи. Если ничего с ними не делать, через какое-то время они разрастутся до гигабайтов и благополучно съедят всё свободное место. Логичное решение — настроить
Я уже успел проверить файловую систему, права, каталоги и конфигурацию. Всё выглядело абсолютно нормально.
Оказалось, проблема вообще не там.
Если посмотреть настройки сервиса:
то выясняется, что
Решение оказалось элементарным:
Пять минут на исправление.
И почти неделя на поиск причины.
Если вам кажется, что какая-то задача простая, скорее всего, вы просто ещё не начали её делать.
Обе истории показывают, что в IT самая сложная часть часто скрыта за самой обычной задачей. То, что выглядит как быстрый пример или простая настройка, на деле может обернуться неделями подготовки и поиска неочевидной причины. Поэтому к любому «это же быстро» лучше сразу относиться с долей скепсиса.
systemd — в почти недельный квест.Провёл вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» на Rebrain. И понял одну простую вещь: самое сложное в докладе — не выступление, а всё, что происходит до него.
Тему я заявлял как обзор технологий Asterisk для разработчиков. Планировал рассказать про четыре инструмента: Dialplan, AGI (Asterisk Gateway Interface), AMI (Asterisk Manager Interface) и ARI (Asterisk REST Interface).
Но реальность быстро внесла свои коррективы. Выяснилось, что ARI даже для простого примера требует слишком глубокого погружения. Тратить несколько недель только ради одной демонстрации не хотелось, поэтому пришлось отказаться.
Со всем остальным тоже оказалось не так просто. На работе эти технологии давно функционируют, и я уже не замечаю, насколько большое окружение за ними стоит. Например, для демонстрации AMI понадобился CDR. Начал поднимать всё с нуля — и сразу выяснилось, что «из коробки» оно не работает.
CDR потребовал MySQL. MySQL оказался привязан не к тому интерфейсу. Исправил. Затем выяснилось, что структура базы данных не подходит под мою версию Asterisk. Переделал. Чтобы показать простую функцию — соединить клиента с тем менеджером, с которым он разговаривал ранее, — пришлось буквально перешерстить полобраза Ubuntu.
Потом решил выложить исходники на GitHub. Часть проекта работала в Docker, поэтому пришлось ещё разбираться с GitHub Actions, чтобы автоматически публиковать Docker-образы. Огромный пласт работы, который никто во время вебинара даже не увидит.
И так было практически с каждой демонстрацией. Со стороны кажется: «показать небольшой пример». На практике — две недели настройки, поиска несовместимостей и чтения документации.
В итоге всё заработало. Но появилась другая проблема. Доклад, который я рассчитывал провести за полтора часа, уложился примерно в сорок минут.
На вебинар зарегистрировались 115 человек. Формат был «открытый микрофон»: после выступления можно заполнить анкету с обратной связью.
И тут финальный штрих.
Анкету заполнил... один человек.
Возможно, тема оказалась слишком узкой. Менеджер Rebrain уже предложила выступить ещё раз в августе. Похоже, в следующий раз придётся выбирать что-то более массовое. Узкоспециализированные темы интересны далеко не всем.
На работе тоже приключение.
Написал скрипт. Всё работает, но он пишет логи. Если ничего с ними не делать, через какое-то время они разрастутся до гигабайтов и благополучно съедят всё свободное место. Логичное решение — настроить
logrotate. Только вот логи почему-то не ротируются.logrotate падал с ошибкой:Файловая система доступна только для чтения
Я уже успел проверить файловую систему, права, каталоги и конфигурацию. Всё выглядело абсолютно нормально.
Оказалось, проблема вообще не там.
Если посмотреть настройки сервиса:
systemctl cat logrotate.service
ProtectSystem=full
то выясняется, что
systemd запускает logrotate в режиме, где каталоги /usr, /boot и /etc доступны только для чтения. А мой лог как раз лежал внутри /usr/local/....Решение оказалось элементарным:
systemctl edit logrotate.service
[Service]
ReadWritePaths=/usr/local/scripts
Пять минут на исправление.
И почти неделя на поиск причины.
Если вам кажется, что какая-то задача простая, скорее всего, вы просто ещё не начали её делать.
Обе истории показывают, что в IT самая сложная часть часто скрыта за самой обычной задачей. То, что выглядит как быстрый пример или простая настройка, на деле может обернуться неделями подготовки и поиска неочевидной причины. Поэтому к любому «это же быстро» лучше сразу относиться с долей скепсиса.
👍2