За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

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

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

Я сделал резервную копию через pg_dump и восстановился из неё 22 раза. Резервные копии делал в 4 разных форматах с использованием от 1 до 7 уровней сжатия под каждый формат. Записал результаты и сделал сравнение разных видов, чтобы понимать, какие способы более эффективны для моего сценария использования.

Детали и замеры — ниже.

Однажды я столкнулся с проблемой, когда почти потерял коммерчески успешный пет-проект из-за устаревших резервных копий БД (ещё до того, как он стал коммерчески неуспешным). При этом, даже после частичного восстановления, все-таки потерял ~30% прибыли от проекта, много нервов и времени.

Это подтолкнуло меня на разработку своего открытого инструмента для бекапа PostgreSQL. С разными хранилищами, уведомлениями при сбоях и health check'ом. Собственно, о том, как я потерял деньги и затем разработал проект — хочу рассказать в статье ниже.

Несколько лет назад я начал добавлять Go в свой арсенал языков (будучи на тот момент Java разработчиком). Мне было очень непривычно. Более того, я принял язык не с первой попытки. Причём пришлось принять его больше из-за сложившихся обстоятельств, чем по собственному желанию.

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

Уточню: статья ориентирована больше на тех, кто планирует перейти в Go, чем для опытных разработчиков.

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

Пару недель назад меня попросили помочь на техническом собеседовании для Senior/Lead backend-разработчика и поделиться опытом. В процессе я формализовал несколько правил, которых придерживаюсь при проверке кандидатов. Чем я и хочу поделиться.

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

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

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

- почему кармический бан — не самое плохое решение;
- как корпоративные блоги помогают авторам и читателям;
- из-за чего Telegram каналы — это выгодный для Хабра компромисс между контентом и рекламой (*с оговорками).

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

Мой обеденный кофе прервался. Начали приходить уведомления от мониторинга, что сайт и API не отвечают, а CloudFlare отдаёт 521-ю ошибку на все запросы. Спустя пять минут ко мне в личку пришли пользователи с жалобами на неработающие приложения. А ещё спустя пять позвонил сооснователь проекта и сказал, что от нас требуют $250 за остановку DDOS'a.

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

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

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

Предположим, вы разработали первую версию вашего IT сервиса. Аудитория Хабра с этим справляется без особых проблем. При этом плюс-минус корректно определили свою целевую аудиторию и продукт действительно нужен. Даже есть первые продажи. Итак, как выйти на стабильный прирост аудитории?

Vim и Emacs — это, пожалуй, самый древний и легендарный «братский» конфликт в мире текстовых редакторов. Одни говорят: «Люди делятся на тех, кто знает Vim, и тех, кто знаком с болью и страданием». Другие возражают: «Emacs на самом деле полноценная операционная система, где просто не хватает хорошего текстового редактора».

Давайте попробуем окунуться в историю этого противостояния и собрать любопытные (а местами и безумные) факты о Vim и Emacs.

Я занимаюсь фронтенд разработкой на React последние 6 лет (в роли full-stack разработчика). Я знал и слышал, что существуют хуки useCallback и useMemo, которые нужны для оптимизации рендеринга. При этом про их использование я слышал только в теории или на собеседованиях.

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

У меня появилась задача в проекте: перевести личный кабинет пользователя на русский и английский языки (в перспективе и на другие языки). При этом, определять язык пользователя при первом заходе в ЛК и запоминать язык при перезагрузке страницы. Разумеется, всё это с типизацией файлов с переводами (чтобы нельзя было забыть добавить любое из полей).

Как я это делал — расскажу в статье.

Предположим, у нас есть проект или идея SaaS продукта. Возможно мы уже разработали первую версию, у нас есть пользователи и в целом мы куда-то движемся. Как понять, что именно разрабатывать дальше, чтобы продукт рос, а пользователи платили? Как понять, какую именно обратную связь принимать от пользователей?

На определённом этапе своей карьеры я задался вопросом: может ли Next.js работать в многопоточном режиме? Оказалось, что нет. Это побудило меня разобраться, как можно организовать многопоточную работу Next.js и насколько это оправдано для сайтов с высокой нагрузкой.

Всем привет! Меня зовут Ростислав и я занимаюсь разработкой мониторинга для сайтов. Это мой пет-проект, если можно его так назвать. Иногда мониторинг сталкивается с проблемой, когда нужно проверить принадлежность сайта конкретному пользователю. Как это делается, я расскажу в статье.

Примеры кода будут на Python (FastAPI, SQLAlchemy, mypy) и Java (Spring, Hibernate). Изначально проект был написан на Python, но по мере роста был переписан на Java для упрощения поддержки и развития. 

Всем привет! Одна из моих рутинных задач - это подъем новых проектов и микросервисов в облаках. Для этого практически всегда нужны домены и поддомены с наличием SSL сертификата. У меня выработался подход, с помощью которого я автоматизировал процесс выдачи сертификатов с помощью certbot. О чём и хочу рассказать.

Шпаргалка по основным секциям Nginx, которые следует держать под рукой. Ниже приведены самые частые функции: включение SSL, переадресация, раздача статики и т.д.

Пишу в продолжение прошлой статьи "Как я заработал 500 000 рублей, сделав доступ к ChatGPT. А потом Яндекс убил SEO и всё (почти) закончилось". В прошлый раз я рассказывал о запуске проекта на базе ChatGPT, а сейчас будут выводы и мысли, к которым я пришёл по ходу разработки проекта.

Статья о том, как я почти проспал "бум" ChatGPT, но сделал к нему доступ и заработал на этом (и продолжаю зарабатывать). Сам проект сейчас идёт на спад, но об этом в конце.

Всем привет! Меня зовут Ростислав, я full-stack разработчик. Последние 3 года у меня есть хобби - доведение пет-проектов до стадии финансово рентабельных IT продуктов. Сейчас я хочу поделиться своими советами о запуске проекта, исходя из своего опыта.