Я читаю IT-книги уже много лет. И много лет мирюсь с одним и тем же: «управление транзакций с помощью повествований» вместо саги, «многоразовый код» вместо переиспользуемого, «конечная точка» вместо эндпоинта. Переводчикам памятник надо ставить за то, что они пытаются, но читать от этого не легче. Особенно когда книга стоит 3000 рублей и ты застрял на одном абзаце, потому что мозг зациклился на не правильном термине.

Оказалось, я не один такой. Есть сообщество разработчиков, которые вычитывают книги до печати — проверяют терминологию, подписи к схемам, логику изложения. Я присоединился и взял на ревью книгу про промт-инжиниринг и разработку приложений на основе LLM от создателей GitHub Copilot. Это дало неожиданный эффект — я читал эту книгу настолько внимательно, насколько это возможно.

Недавно снова услышал вайб: да все эти принципы это только направление и их можно не придерживаться. И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно. У нас же все теперь гибко и как договоритесь. И требовать каких-то стандартов отрасли - это уже абьюз…

Интеграционные тесты тормозят и не нужны, линтер можно и не использовать. Нарушение архитектурных принципов - так мы ж делаем MVP - зачем оно нам?

Я в корне не согласен с таким подходом и буду это разбирать на примере SOLID и перфораторной дрели...

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

И о решении, которое подойдёт не только мне.

Привет! Я Лёша, backend‑разработчик, который любит путешествовать. Зато я увлёкся нейронками и доработал самописный Telegram-бот, который мониторит цены на туры и перелёты. Статья будет как раз про ИИ с точки зрения внедрения в пет-проект.

Под катом узнаете:

— где стоит применить нейронки, а где можно обойтись NLP;

— как локально крутить LLM и почему стоит воспользоваться API;

— как подбирать промпты, чтобы получать от ИИ не просто ответы, а реально полезную информацию;

— зачем вообще в боте для поиска дешёвых авиабилетов (и любых сообщений) нейросети и почему в нём осталась лемматизация / NLP, а в некоторых местах регулярки для поиска сообщений.

Два месяца назад я написал Телеграм-бот, который помогает мне выхватывать дешёвые авиабилеты (и нет, это не рекламная интеграция). Я прикрутил Python-интеграцию к Telegram по протоколу для клиентов, чтобы читать сообщения из любых публичных групп, к backend-части на Spring — она позволяет через бота подписываться на эти группы и настраивать, какие сообщения выхватывать для вас.

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

Я реанимировал бот, добавил несколько киллер-фичей и готов поделиться с вами всеми наработками. В статье найдёте код, ссылки на бот и примеры, как другие пользователи ищут через бот скидки на айфоны и много чего ещё.

Вы же попались на этот кликбейт?

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

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

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

Мне посчастливилось работать в одной очень крутой и заботливой компании, которая закрывала выше описанные мною потребности. То есть оплачивала групповые интересы своих сотрудников. Так я ходил с переменным постоянством на сквош, большой теннис, скалолазанье, гонку героев. Кроме этого было еще много коммьюнити - это и настольные игры, и занятия по пению, футбол, воллейбол, беговой клуб и скорее всего что-то еще что я не смог вспомнить. Честно говоря, такая забота меня просто поразила и я нигде такого не встречал.

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

У участников этого коммьюнити была проблема, на которой они чаще всего жаловались. Это способ записи на еженедельную тренировку. Дело в том, что на каждое коммьюнити компания выделяла определенный бюджет. И конкретно в большом теннисе его хватало на 2 тренировки в неделю максимальной вместимости по 8 чел в группе. При этом желающих в зависимости от сезона было больше чем могла вместить группа.

Привет! Этим постом я завершаю цикл из конспектов видеолекция Дяди Боба про чистый код.

Сегодня обсудим обработку исключений, комментарии к коду, форматирование, размеры файлов и дата-классы.

Обработка исключений

Не раскрывайте реализацию

Майкл Физерс (Working effectively with legacy code) сказал: «Если обработка ошибок раскрывает реализацию — то это неправильная обработка ошибок». Не раскрывать реализацию можно, если написать исключения перед тем, как написать реализацию функции (привет TDD — по-другому и не получится).

Рассмотрим классCommissionCalculator , который обменивает сумму в разных валютах.

Привет! Продолжаем цикл постов про чистый код по мотивам видеолекций Дяди Боба, первая часть тут. В этом посте поговорим про структуру функций и не только.

Передача булевых аргументов

Чаще всего передача булевых аргументов говорит о том, что функция делает сразу две вещи, а это значит, что она нарушает принцип единственности ответственности, и у нас должно быть две функции. Например, есть какая-нибудь функция createPayment, которая делает что-то одно, если это токен, и делает что-то другое, если это карточный платеж.

Привет! В этом посте я хочу обсудить, что такое чистый код и почему я считаю его очень важной практикой. Если у вас всё руки не доходили до того, чтобы сесть и подробно почитать книги Дяди Боба, я подготовил небольшой конспект по его видеолекциям со своими примерами с самым главным.

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

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

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

Поэтому я люблю метрики — они помогают убедиться в том, что все идет хорошо. О метриках отношений микросервисов и будет этот пост. Меня зовут Алексей Лашнев, я продуктовый разработчик в QIWI.