Дед Мазай на Котлине

Составил небольшую книжку по разработке бэкенд-приложения на Go. Посмотреть можно тут: https://github.com/MikhailEpatko/GoBook

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

Недавно обсуждали с коллегами этот вопрос и вот, до чего договорились. Файл .env для хранения секретов для фронта не подходит, т.к.: 1) файл .env хранится в репозитории с кодом и секреты из него будут доступны всем, кто имеет доступ к репозиторию с кодом, 2) как правило, приложение для запуска собирается в контейнер (например, докер-контейнер). При использовании .env файла, нужно: - отдельно собирать контейнер для разных окружений (для разработки, для тестов и для продуктива), - продумывать механизм подстановки разных ...

В интернете есть немало статей и докладов, описывающих различные подходы к тестированию приложений: от TDD до "тестируем пользователями в проде". Какой из них лучший? И вообще, стоит ли выбирать какой-то один подход и всегда его придерживаться? На эти вопросы нет однозначного ответа. Каждый должен сам для себя выбрать то, что поможет ему решать его задачи наиболее эффективно. Я, как и бльшинство моих коллег, при тестировании бэкенд-приложений придерживаемся следующих правил: 1) по-максимуму автоматизировать тестирование...

Если для валидации входящих запросов в Spring Boot на Kotlin вы используете библиотеку spring-boot-starter-validation, то эта статья будет для вас полезна. Работа с библиотекой в Kotlin имеет одну особенность, вязанную с использованием non nullable Kotlin-типов. Рассмотрим тестовый проект. В контроллере есть 2 эндпоинта (2 функции). Один принимает запрос с полем nullable типа. Второй — принимает запрос с полем non nullable типа. Входящие параметры обеих функций помечены аннотацией @Valid. Поля обеих моделей запросов помечены аннотацией @NotBlank...

На днях, очень оживлённо обсуждали с коллегами один интересный подход к написнию кода. Хочу поделиться с вами некоторыми его деталями и пригласить присоединиться к обсуждению. Представим, что у нас есть некоторая сущность, соответствующая одноимённой таблице в базе данных: @Table(value = "employee") data class EmployeeEntity( @Id val id: Long? = null, @Column("name") val name: String, ) Модель, которая соответствует этой сущности, я и мои коллеги-котлинисты привыкли писать примерно...

Вопрос про размер пулла соединений к базе данных. Многие из вас могли видеть в настройках пулла такие параметры как: spring.datasource.hikari.connectionTimeout=2000 spring.datasource.hikari.maximum-pool-size=100500 spring.datasource.hikari.maxLifetime: 1000000 Как долго вы думали над тем: - откуда взяты значения этих параметров? - почему в вашем приложении решили применять именно такие, а не какие-то другие значения? Знаю, что на многих проектах настройки кочуют из самых ранних приложений в более новые...

У технического долга есть много определений. Самое короткое и самое ёмкое из них: это то, что мешает команде работать с заданной скоростью. Заданная скорость - это скорость реализации задач, взятая командой в начале проекта, когда технический долг минимален или совсем отсутствует. Чем плох технический долг? Один из эффектов, который имеет технический долг - он замедляет разработку. Причём, эффект этот увеличивается со временем. И увеличивается настолько неизбежно, что даже есть популярное сравнение...

Части 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 45. Логи пишем на русском языке. Если видим, что где-то в приложении есть логи на другом языке - исправляем на русский. Это правило не касается логов, которые пишут сторонние библиотеки. 46. Для удобства поиска по логам, рекомендуется логировать request_id (trace_id). Request_id (trace_id) получаем из соответствующего заголовка запроса. При обращении к другим пиложениям также добавляем request_id (trace_id) в заголовок запроса. 47. Приложение, запущенное на стенде dev, demo, prod должно отдавать логи в STDOUT (консоль) в JSON-формате...

Части 1, 2, 3, 4, 5, 6, 7, 8, 9 Сборник правил по проектированию API. 26. Нестрого придерживаемся правил REST-архитектуры. Если какое-то правило необоснованно осложняет разработку, допускается его обойти. 27. Используем семантическое версионирование приложения. 28. Корень для всех внешних API приложения должен быть указан явно. Например: /api 29. Корень для всех внутренних API приложения должен быть указан явно. Например: /internal 30. Версию приложения (см.п.27) должно быть видно по адресу: GET http://host:port/api/actuator/info 31...

Части 1, 2, 3, 4, 5, 6, 7, 8 24. В базе данных и в коде нельзя толковать null как самостоятельное значение Его нужно толковать как "мы не знаем что это, оно может быть чем угодно". Использовать null в другом качестве (понимать под ним какое-то определённое значение или число, думать, что null больше или меньше каких-то не null значений) недопустимо. Если нужно, чтобы вместо "мы не знаем, что это" было какое-то значение, то вместо null нужно присваивать переменной какое-то осмысленное значение. 25...

Заголовок провокационный, да? ) И так – чтобы не было недопонимания – что я понимаю под код-ревью в этой статье: процесс проверки кода одного разработчика другим разработчиком (или несколькими рзработчиками) на стадии перед выполнением мержа фиче-ветки в основную ветку. Обычно, задачи перед код-ревью ставятся следующие: 1) контроль качества кода, 2) ознакомление других разработчиков с изменениями в коде. Теперь, давайте, разберёмся, почему код-ревью не выполняет эти задачи. Почему не работает “код-ревью...